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

[Alexander Best]

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

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

> > > > > Alex Dupre schrieb am 2009-11-06:
> > > > > > Alexander Best ha scritto:
> > > > > > > i dug up this old pr
> > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/59739

> > > > > > I think the EISDIR error is coming from kern/vfs_lookup.c,
> > > > > > lookup()
> > > > > > function with cn_nameptr = "":


> > > > > >         /*
> > > > > >          * Check for degenerate name (e.g. / or "")
> > > > > >          * which is a way of talking about a directory,
> > > > > >          * e.g. like "/." or ".".
> > > > > >          */
> > > > > >         if (cnp->cn_nameptr[0] == '\0') {
> > > > > >                 ...
> > > > > >                 if (cnp->cn_nameiop != LOOKUP) {
> > > > > >                         error = EISDIR;
> > > > > >                         goto bad;
> > > > > >                 }
> > > > > >                 ...

> > > > > thanks a lot for finding the problem in the src. what do you
> > > > > think
> > > > > of the
> > > > > patch attached to this message? after applying it the example
> > > > > code
> > > > > i posted in
> > > > > my previous message returns the following output (instead of
> > > > > EISDIR):

> > > > > rmdir errno: 16 (which is EBUSY)
> > > > > mkdir errno: 17 (which is EEXIST)

> > > > > i don't know if these really are the correct return values,
> > > > > but
> > > > > it's what the
> > > > > originator of the PR requested.


> > > > What if cn_nameiop is != LOOKUP but also neither DELETE nor
> > > > CREATE,
> > > > assuming that case is possible?  I'd leave the original
> > > > if-clause
> > > > at
> > > > the end to catch that.

> > > > ---
> > > > Gary Jennejohn

> > > how about this patch?

> > > 1. i've added "if (cnp->cn_nameiop != LOOKUP)" although i don't
> > >    think it's
> > > necessary since the first blocks should cover all the possible
> > > cases.
> > > 2. i've used rename() to test the case (cnp->cn_nameiop !=
> > >    RENAME).
> > >    is this
> > > correct or does rename() use a combo of DELETE and CREATE?
> > > problem
> > > is that the
> > > rename(2) manual doesn't seem to cover the case that arg 1 is a
> > > mountpoint.
> > > right now EBUSY gets returned if cnp->cn_nameiop != RENAME.
> > > however
> > > BUSY needs
> > > to be added to all manuals which use cnp->cn_nameiop != RENAME
> > > (shouldn't be
> > > too many). or are there any other suggestions what rename()
> > > should
> > > return if
> > > arg 1 is a mountpoint?


> > Hmm. In rename(2) there's

> > [EINVAL]           The from argument is a parent directory of to,
> > or
> > an
> >                    attempt is made to rename `.' or `..'.

> > and a few lines below your patch this case is handled for ISDOTDOT
> > for both RENAME and DELETE.  I don't see off hand where renaming or
> > deleting "." is handled.

> > According to the comment above your patch the case of "/." or "."
> > is
> > being checked, which would seem to correspond to the above part of
> > rename(2), i.e. perhaps EINVAL should be returned for RENAME and
> > DELETE.

> > ---
> > Gary Jennejohn


> that would be an option. however in the case of rmdir(2) EINVAL and
> EBUYS
> would both fit. depends whether be forbid deletion of / because it is
> a
> mountpoint or because / is actually /. and paths ending with . are
> forbidden
> as arg in rmdir(2).

> i guess we have to take a look at the POSIX specs before we can
> decide how to
> handle this.

> also i've discovered that permission checks for / seem to be handled
> differently than any other dir. on my machine /usr is a mountpoint.
> doing
> rmdir /usr returns EACCES as regular user and EBUSY as superuser.
> doing rmdir
> / as regular user however doesn't seem to check permission but
>   returns EBUSY
> right away. but that's not a problem i guess. this is probably
> happening
> because the kern/vfs_lookup.c code is being executed before anything
> else
> (including permission checks).

> i'll have a look what POSIX has to say about the return values. but i
> agree
> with you. returning EINVAL seems logical.

> alex.

ok. here it goes. POSIX says:

rmdir()
[http://www.opengroup.org/onlinepubs/9699919799/functions/rmdir.html#tag_16_618]:
If the directory is the root directory or the current working directory of any
process, it is unspecified whether the function succeeds, or whether it shall
fail and set errno to [EBUSY].

mkdir()
[http://www.opengroup.org/onlinepubs/9699919799/functions/mkdir.html#tag_16_372]:
nothing regarding /.

rename()
[http://www.opengroup.org/onlinepubs/9699919799/functions/rename.html#tag_16_614]:
If either pathname argument refers to a path whose final component is either
dot or dot-dot, rename() shall fail.

so at least rmdir() should return EBUSY. also POSIX defines EBUSY for return()
which isn't documented in our return(2) manual.

alex