From owner-freebsd-hackers Sun Apr 1 21: 5:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from maxim.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id B08BA37B71B for ; Sun, 1 Apr 2001 21:05:15 -0700 (PDT) (envelope-from gjb@gbch.net) Received: (qmail 4847 invoked by uid 1001); 2 Apr 2001 14:05:07 +1000 Message-ID: X-Posted-By: GJB-Post 2.13 09-Feb-2001 X-Operating-System: FreeBSD 4.2-RELEASE i386 X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-GPG-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-PGP-Public-Keys: http://www.gbch.net/keys.html Date: Mon, 02 Apr 2001 14:05:06 +1000 From: Greg Black To: Robert Watson Cc: freebsd-hackers@FreeBSD.ORG, Bill Moran Subject: Re: Security problems with access(2)? References: In-reply-to: of Sun, 01 Apr 2001 23:02:11 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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