namei() returns EISDIR for "/" (Re: svn commit: r203990 - head/lib/libc/sys)

[Nate Eldredge]

On Sun, 28 Feb 2010, Garrett Cooper wrote:

> On Sun, Feb 28, 2010 at 5:11 PM, Alexander Best <alexbestms at 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
nate at thatsmathematics.com