rmdir(2) and mkdir(2) both return EISDIR for argument "/"

[Alexander Best]

Gary Jennejohn schrieb am 2009-11-07:
> On Fri, 06 Nov 2009 22:09:49 +0100 (CET)
> Alexander Best <alexbestms at math.uni-muenster.de> wrote:

> > here's a completely new patch. all the changes are in
> > kern/vfs_syscall.c. so
> > kern/vfs_lookup.c now stays just the way it is (please revert any
> > changes from
> > the previous patches i posted).

> > after applying the patch this is the output from a slightly
> > modified version
> > of the test app i attached in my very first post:

> > rmdir errno: 16 (EBUSY) <- EBUSY is required by POSIX
> > mkdir errno: 17 (EEXIST)
> > rename errno: 22 (EINVAL)

> > these are the results when called with "/" as arg. the output
> > doesn't differ
> > if run with or without superuser privileges.

> > when run with "." as arg this is the output as regular user:

> > rmdir errno: 22 (EINVAL)
> > mkdir errno: 17 (EEXIST)
> > rename errno: 13 (EACCES)

> > and as superuser:

> > rmdir errno: 22 (EINVAL)
> > mkdir errno: 17 (EEXIST)
> > rename errno: 22 (EINVAL)

> > does this look reasonable? would be nice if mkdir and rmdir would
> > also check
> > privileges at first like rename, but that's a different story i
> > guess. ;)


> The only problem I see with this is that vfs_syscall.c now has
> knowledge
> about the internal details of vfs_lookup.c

> Maybe just mention in the comments that this is the case and could be
> a problem if vfs_lookup.c is changed for some reason?  That's what I
> do when I have to use something like this.

> But we don't want to turn this into a gigantic bikeshed - we already
> have enough of those.

> ---
> Gary Jennejohn

well like you said there are 2 possibilities of dealing with this:

1. in vfs_lookup.c or
2. in vfs_syscall.c

personally i think vfs_syscall.c is the better solution. i only tested
rmdir(), rename() and mkdir(). however lots of other apps/functions might be
depending on vfs_lookup.c and are expecting namei() to return EISDIR for
arg="/". if we change this behaviour we might break a lot of other stuff.

also looking at vfs_syscall.c shows that a lot of code in there already
depends and knows about vfs_lookup.c internal details. so we wouldn't be
changing the whole vfs_syscall.c semantics.

but you're right. this is the perfect topic for a bikeshed. ;)

i'll wait for a few more days and if nobody has a problem with the last patch
i'll submitted it as followup to kern/59739.

thanks a lot for your help. :)

cheers.
alex