Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Oct 2002 19:03:23 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        David Schultz <dschultz@uclink.Berkeley.EDU>
Cc:        Peter Jeremy <peter.jeremy@alcatel.com.au>, The Anarcat <anarcat@anarcat.ath.cx>, FreeBSD Security Issues <FreeBSD-security@FreeBSD.ORG>
Subject:   Re: access() is a security hole?
Message-ID:  <20021011185423.B12227-100000@gamplex.bde.org>
In-Reply-To: <20021010193137.GA13547@HAL9000.homeunix.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 10 Oct 2002, David Schultz wrote:

> Thus spake Peter Jeremy <peter.jeremy@alcatel.com.au>:
> > On 2002-Oct-08 17:23:35 -0400, The Anarcat <anarcat@anarcat.ath.cx> wrote:
> > >Also, this means that the stat() manpage should also contains a
> > >similar section about its non-fd incarnations.
> >
> > I disagree.  access(2) is specifically designed to allow setuid/setgid
> > programs to validate access rights based on the real uid/gid - but is
> > virtually impossible to use safely for this task because of the
> > inherent race conditions.
>
> No, access(2) is designed to allow NON-setuid programs to easily
> do sanity checks without opening a file or device right away.
> There's still a race condition, but it isn't typically a security
> threat when all you're trying to do is prevent the user from
> shooting himself in the foot.  To use access() in a setuid program
> is usually an error.

No, it was designed to be useful to setuid programs.  Whether it
actually is useful is arguable.  From the V7 manual:

    "The user and group IDs with respect to which permission is checked
    are the real UID and GID of the process, so that this call is useful
    to set-UID programs".

Setuid programs should only use access() to check whether they will
have permission after they set[ug]id() to the real [ug]id.  Non-setuid
programs mostly don't need such checks.  They can just try the operation.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021011185423.B12227-100000>