Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 07 Nov 2009 12:45:32 +0100 (CET)
From:      Alexander Best <alexbestms@math.uni-muenster.de>
To:        <gary.jennejohn@freenet.de>, Alexander Best <alexbestms@math.uni-muenster.de>
Cc:        freebsd-hackers@FreeBSD.org
Subject:   Re: rmdir(2) and mkdir(2) both return EISDIR for argument "/"
Message-ID:  <permail-200911071145321e86ffa80000710d-a_best01@message-id.uni-muenster.de>
In-Reply-To: <20091107112116.50eb45ee@ernst.jennejohn.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Gary Jennejohn schrieb am 2009-11-07:
> On Fri, 06 Nov 2009 22:09:49 +0100 (CET)
> Alexander Best <alexbestms@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?permail-200911071145321e86ffa80000710d-a_best01>