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>