Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 06 Nov 2009 22:09:49 +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-20091106210949f0889e8400000862-a_best01@message-id.uni-muenster.de>
In-Reply-To: <20091106182308.14dffc50@ernst.jennejohn.org>

next in thread | previous in thread | raw e-mail | index | archive | help
  This is a MIME encoded multipart message.

--+permail-20091106210949f0889e8400000862-a_best01+
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Gary Jennejohn schrieb am 2009-11-06:
> On Fri, 06 Nov 2009 17:43:06 +0100 (CET)
> Alexander Best <alexbestms@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@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

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. ;)

alex

--+permail-20091106210949f0889e8400000862-a_best01+
Content-Type: text/plain
Content-Transfer-Encoding: Base64
Content-Disposition: attachment; filename="vfssyscalls.c.patch.txt"

LS0tIHZmc19zeXNjYWxscy5jCTIwMDktMTEtMDYgMjI6MDc6MDguMDAwMDAwMDAwICswMTAwCisr
KyAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3lzY2FsbHMuYwkyMDA5LTExLTA2IDIxOjM3OjQ3LjAw
MDAwMDAwMCArMDEwMApAQCAtMzUsNyArMzUsNyBAQAogICovCiAKICNpbmNsdWRlIDxzeXMvY2Rl
ZnMuaD4KLV9fRkJTRElEKCIkRnJlZUJTRCQiKTsKK19fRkJTRElEKCIkRnJlZUJTRDogaGVhZC9z
eXMva2Vybi92ZnNfc3lzY2FsbHMuYyAxOTY4ODcgMjAwOS0wOS0wNiAxMTo0NDo0Nloga2liICQi
KTsKIAogI2luY2x1ZGUgIm9wdF9jb21wYXQuaCIKICNpbmNsdWRlICJvcHRfa2R0cmFjZS5oIgpA
QCAtMzU4Nyw4ICszNTg3LDEyIEBACiAJICAgIEFVRElUVk5PREUxLCBwYXRoc2VnLCBvbGQsIG9s
ZGZkLCB0ZCk7CiAjZW5kaWYKIAotCWlmICgoZXJyb3IgPSBuYW1laSgmZnJvbW5kKSkgIT0gMCkK
KwlpZiAoKGVycm9yID0gbmFtZWkoJmZyb21uZCkpICE9IDApIHsKKwkJLyogVHJhbnNsYXRlIGVy
cm9yIGNvZGUgZm9yIHJlbmFtZSgiLyIsICJkaXIyIikuICovCisJCWlmIChlcnJvciA9PSBFSVNE
SVIpCisJCQllcnJvciA9IEVJTlZBTDsKIAkJcmV0dXJuIChlcnJvcik7CisJfQogCWZ2ZnNsb2Nr
ZWQgPSBOREhBU0dJQU5UKCZmcm9tbmQpOwogCXR2ZnNsb2NrZWQgPSAwOwogI2lmZGVmIE1BQwpA
QCAtMzczNyw4ICszNzQxLDEyIEBACiAJTkRJTklUX0FUKCZuZCwgQ1JFQVRFLCBMT0NLUEFSRU5U
IHwgU0FWRU5BTUUgfCBNUFNBRkUgfCBBVURJVFZOT0RFMSwKIAkgICAgc2VnZmxnLCBwYXRoLCBm
ZCwgdGQpOwogCW5kLm5pX2NuZC5jbl9mbGFncyB8PSBXSUxMQkVESVI7Ci0JaWYgKChlcnJvciA9
IG5hbWVpKCZuZCkpICE9IDApCisJaWYgKChlcnJvciA9IG5hbWVpKCZuZCkpICE9IDApIHsKKwkJ
LyogVHJhbnNsYXRlIGVycm9yIGNvZGUgZm9yIG1rZGlyKCIvIikuICovCisJCWlmIChlcnJvciA9
PSBFSVNESVIpCisJCQllcnJvciA9IEVFWElTVDsKIAkJcmV0dXJuIChlcnJvcik7CisJfQogCXZm
c2xvY2tlZCA9IE5ESEFTR0lBTlQoJm5kKTsKIAl2cCA9IG5kLm5pX3ZwOwogCWlmICh2cCAhPSBO
VUxMKSB7CkBAIC0zODI1LDEwICszODMzLDE1IEBACiAJYndpbGx3cml0ZSgpOwogCU5ESU5JVF9B
VCgmbmQsIERFTEVURSwgTE9DS1BBUkVOVCB8IExPQ0tMRUFGIHwgTVBTQUZFIHwgQVVESVRWTk9E
RTEsCiAJICAgIHBhdGhzZWcsIHBhdGgsIGZkLCB0ZCk7Ci0JaWYgKChlcnJvciA9IG5hbWVpKCZu
ZCkpICE9IDApCisJaWYgKChlcnJvciA9IG5hbWVpKCZuZCkpICE9IDApIHsKKwkJLyogVHJhbnNs
YXRlIGVycm9yIGNvZGUgZm9yIHJtZGlyKCIvIikuICovCisJCWlmIChlcnJvciA9PSBFSVNESVIp
CisJCQllcnJvciA9IEVCVVNZOwogCQlyZXR1cm4gKGVycm9yKTsKKwl9CiAJdmZzbG9ja2VkID0g
TkRIQVNHSUFOVCgmbmQpOwogCXZwID0gbmQubmlfdnA7CisJLyogWFhYIG5hbWVpKCkgdGFrZXMg
Y2FyZSBvZiB0aGlzIGNhc2UuICovCiAJaWYgKHZwLT52X3R5cGUgIT0gVkRJUikgewogCQllcnJv
ciA9IEVOT1RESVI7CiAJCWdvdG8gb3V0OwpAQCAtMzg0MSw2ICszODU0LDcgQEAKIAkJZ290byBv
dXQ7CiAJfQogCS8qCisJICogWFhYIG5hbWVpKCkgdGFrZXMgY2FyZSBvZiB0aGlzIGNhc2UuCiAJ
ICogVGhlIHJvb3Qgb2YgYSBtb3VudGVkIGZpbGVzeXN0ZW0gY2Fubm90IGJlIGRlbGV0ZWQuCiAJ
ICovCiAJaWYgKHZwLT52X3ZmbGFnICYgVlZfUk9PVCkgewo=

--+permail-20091106210949f0889e8400000862-a_best01+--



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