Date: Sat, 31 Mar 2001 17:39:31 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Greg Black <gjb@gbch.net> Cc: Bill Moran <wmoran@iowna.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: Security problems with access(2)? Message-ID: <Pine.NEB.3.96L.1010331173532.40815M-100000@fledge.watson.org> In-Reply-To: <nospam-986073263.85140@maxim.gbch.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 1 Apr 2001, Greg Black wrote: > There is only one reason to use access() and that's to discover if a > file is accessible. Because of the race condition and the fact that > access() tells lies to setuid and setgid programs, it is both dangerous > and useless unless used with such care that any benefits it provides are > lost in the noise. Actually, there are a number of legitimate reasons that a program might wish to determine the accessibility of a file. However, in my view access(2) is mis-specified. Really, I would like it to generate results based on the effective uid and gid of the process, not the real uid and gid, so it could allow applications to defer to kernel policy for accessibility when generating output for the user. However, instead it uses the real uid and gid in a manner likely to induce races. The scenario for access(2) that I have in mind would be for GUI's that want to display (for example), a read-only version of an icon. Deriving the read-only status from the results of stat() (and friends) means replicating the kernel protection policy in userland, which breaks for ACL-enabled, MAC, BSD file flags, capability, superuser, DTE, ... environments. I.e., the userland process cannot adequately determine its access rights to a file purely based on available output from stat(), and really shouldn't try. Unfortunately, access(2) does the wrong thing. :-) However, access(2) is defined in some or another spec, possibly SUS or POSIX. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" 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.1010331173532.40815M-100000>