Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Oct 2002 15:47:17 -0400 (EDT)
From:      Robert Watson <rwatson@FreeBSD.ORG>
To:        Giorgos Keramidas <keramida@ceid.upatras.gr>
Cc:        Ricardo Anguiano <anguiano@codesourcery.com>, Chris BeHanna <behanna@zbzoom.net>, FreeBSD Security <security@FreeBSD.ORG>
Subject:   Re: access() is a security hole?
Message-ID:  <Pine.NEB.3.96L.1021015154020.27939C-100000@fledge.watson.org>
In-Reply-To: <20021013154127.GA2970@hades.hell.gr>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sun, 13 Oct 2002, Giorgos Keramidas wrote:

> > What's wrong with opening the file, then using fstat to check the
> > properties of the file associated with the file descriptor?
> 
> Sometimes, just opening a `file' has interesting side-effects.  For
> instance, opening a rewinding tape device will start the tape rewinding
> process.  You might not want to cause such side-effects to happen :-/

There are a number of scenarios where I've used access(2) and eaccess(2)
to useful effect.  They include:

(1) Situations where the goal is to render possible access rights for the
    user, rather than simulate an access.  For example, KDE uses the
    access() system call when rendering file and directory icons to
    suggest to the user whether or not they can access the directory.
    Using a call such as access(2) is *much* preferred over the use of
    stat() to retrieve permissions and manually calculate rights, as that
    doesn't take into account ACLs, MAC, distributed file system
    alternative protection semantics, etc.

    BTW, because KDE used access() to figure out how to render icons, it
    required no modification when we introduced ACLs and MAC in TrustedBSD
    in order to correctly render directories.  It did require some
    modifications to support changing the protections on the files, of
    course, but that use of access() has definite advantages from a UI
    perspective.

(2) Situations where the goal is to produce a more clean failure mode for
    compound operations.  While it's true that it's generally better for
    an application to "try" the operation and see if it succeeds, there
    are cases where it's preferable to at least give a pass at predicting
    the result so as to offer a cleaner failure mode.  For example, if an
    application is installing files onto a system, performing a set of
    access() checks on target directories can result in a clean failure
    mode "One or more directories you need to write to is unwritable",
    whereas merrily wandering along installing until you hit the first
    unwritable directory leaves a cleanup/backout problem.  While this
    won't capture all possible failure modes ("out of disk space"), it can
    be substantially more user friendly.

(3) Access to any object where the access has side effects, be they
    literal side effects (tape rewind) or just performance ones.

I MFC'd my access() security warning clarification from -CURRENT to
-STABLE, but it could probably use a little more work to take into acount
some of these situations where access() may be the only tool that works. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org      Network Associates Laboratories



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?Pine.NEB.3.96L.1021015154020.27939C-100000>