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>