Date: Sun, 1 Apr 2001 23:02:11 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: freebsd-hackers@FreeBSD.ORG Cc: Greg Black <gjb@gbch.net>, Bill Moran <wmoran@iowna.com> Subject: Re: Security problems with access(2)? Message-ID: <Pine.NEB.3.96L.1010401225435.77053E-100000@fledge.watson.org> In-Reply-To: <20010401190458.A4991@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 1 Apr 2001, David O'Brien wrote: > On Sun, Apr 01, 2001 at 10:55:23AM +1000, Greg Black wrote: > > Many years ago I implemented a new interface that I called > > eaccess() which replicated the work of access, but tested > > against the effective uid and gid. I'd like to see that > > introduced more widely. > > That still isn't suffient (and even more scary) unless the parameter is > a file handle or FILE pointer. We need an faccess() call, plain and > simple. As we've discussed off-line, it sounds like what we probably need here are the following: eaccess_file(2) - Using effective credentials, check to see if the requested access is permitted on the file or directory identified by the provided pathname. eaccess_fd(2) - Using effective credentials, check to see if the requested access is permitted on the file or directory associated with the provided open file descriptor. faccess(3) - Using effective credentials, check to see if the requested access is permitted on the file or directory associated with the provided open file stream. Note: the credentials used for eaccess_fd() and faccess() would *not* use the cached credentials associated with the open file descriptor, instead, the effective credentials of the process, meaning that the result would be with respects to the next fd-independent operation performed by the process (unlink(), rename(), open(), ...). Note that, as I described to you previously (and for the benefit of those not privvy to our conversation), it is not sufficient to provide open() as a means to evaluate credentials and an access request for an object, as open() cannot be used on all file system objects. In particular, open() cannot be used on directories in NFS. I've had local implementations of eaccess_file() and eaccess_fd() for a while, as I've used them in GUI-related work so as not to use access(), and not to manually evaluate credentials in userland. Mapping faccess() into eaccess_fd() should be relatively straight-forward, modulo the usual thread-safety in libc. Are we barking up the wrong tree here, or is this in-line with the requirements, and something we should consider implementing and working with to determine whether it meets the needs of various potential consumers? Needless to say, these would be carefully documented, much in the style of access(2), to indicate that these are only appropriate for use in a set of circumstances where the caller is performing a race-free activity. For example, displaying the result to the user in the form of an icon selection, or using access(2) to provide clean failure in a multi-step activity, where the actual access control is performed by the kernel in open(), but the application wants to provide early failure notification so as to fail more cleanly. 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.1010401225435.77053E-100000>