Gary Jennejohn schrieb am 2009-11-07: > On Fri, 06 Nov 2009 22:09:49 +0100 (CET) > Alexander Best <alexbes...@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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"