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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
