Re: [gamin] Re: gamin library

[Daniel Veillard <veillard redhat com>]

On Tue, Jul 27, 2004 at 04:54:04PM +0200, y9toi7y02 sneakemail com wrote:
> > > > On Tue, Jul 27, 2004 at 03:16:50PM +0200, Martijn Vernooij
> > > wrote:
> > > > > Isn't there a temp file vulnerability in gamin_connect_unix_socket if
> > > > > 'HAVE_ABSTRACT_SOCKETS' isn't defined?
> > > >
> > > >   Well the process should run under the same account as both the server
> > > > and the client check - using the first null byte exchanged - that the
> > > > other side uid is the same. There is no vulnerability in the sense
> > > > that you can be fooled only by a process running at the same priviledge.
> > > > This can also be worked around by defining GAM_CLIENT_ID environment to
> > > > be a unique ID.
> > >
> > > It's not about the server trusting clients when it should not, it's about
> > > what would happen if someone placed a symbolic link pointing to one of the
> > > user's files in /tmp/fam-<username>- before the library is started. It's
> > > not unreasonable to believe the user's file would be truncated or
> > > replaced.

  That's not clear to me. the path is only used for a connect() call at the
library level in gamin_connect_unix_socket() this should not destroy data
in any way.
  On the server side the code does the following in gam_listen_unix_socket:
    if (stat(path, &st) == 0 && S_ISSOCK(st.st_mode)) {
      ...
      ret = unlink(path);
    
so I believe the current code would not override or modify a symlink.
At worse the given /tmp/fam-<username>- link or resource would get removed
but certainly not overriden since man 2 unlink states

   "If the name referred to a symbolic link the link is removed."

I don't see a path for data loss so far.

> > > Creating temporary files without unpredictable names is very hard to do
> > > securely and is the source of many security holes. I don't know the
> > > semantics of the unix socket system in this regard but I think it is
> > > not defined what will happen.

  I think in that case trying and checking the code is a good idea,

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/