On Sun, 28 Feb 2010, Garrett Cooper wrote:
On Sun, Feb 28, 2010 at 5:11 PM, Alexander Best <alexbes...@wwu.de> wrote:
i have a small test app to check {rm|mk}dir()'s errnos with certain args like
/, ., /proc and non-empty dirs. i'll submit it to this thread as soon as i
also add testcases for syscalls like rename(), unlink(), etc.
most of the errno codes returned after applying your patch look correct. i
wonder however why rmdir("/proc") returns EACCESS as unprivileged user.
wouldn't it make more sense to also return EBUSY? why complain about
permission related matters when even root won't be able to perform the
operation.
Hmm.. good question. POSIX doesn't fully expound on this case
(http://www.opengroup.org/onlinepubs/009695399/functions/rmdir.html),
and either seem possible...
At:
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_03.html#tag_02_03
we have
If more than one error occurs in processing a function call, any one of
the possible errors may be returned, as the order of detection is
undefined.
So we're okay standard-wise.
In general, though, I'd think it makes sense to do permissions checks
before anything else, because in some cases the error code can leak
information. For instance, if you try to open() a nonexistent file in a
directory for which you don't have search permission ('x' bit), it's very
important that open() fail with EACCES instead of ENOENT, since you aren't
suppposed to be able to find out whether or not the file exists.
Obviously that doesn't apply in this case, because anyone is entitled to
know that /proc is the root of a mounted filesystem, but it seems to me
that it's a good habit to check permission first.
--
Nate Eldredge
n...@thatsmathematics.com
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
