Date: Mon, 02 Apr 2001 14:05:06 +1000 From: Greg Black <gjb@gbch.net> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: freebsd-hackers@FreeBSD.ORG, Bill Moran <wmoran@iowna.com> Subject: Re: Security problems with access(2)? Message-ID: <nospam-986184307.04846@maxim.gbch.net> In-Reply-To: <Pine.NEB.3.96L.1010401225435.77053E-100000@fledge.watson.org> of Sun, 01 Apr 2001 23:02:11 -0400 References: <Pine.NEB.3.96L.1010401225435.77053E-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: | 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. I like the way you have proposed this and I think it's a good scheme. I do think it might be a good thing to try to get some support from other camps in the interests of wider portability. 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?nospam-986184307.04846>