On Mon, 2006-09-04 at 22:23 -0400, Trond Myklebust wrote:
> On Mon, 2006-09-04 at 12:52 +0100, David Howells wrote:
> > Andrew Morton <akpm@xxxxxxxx> wrote:
> >
> > > sony:/home/akpm> ls -l /net/bix/usr/src
> > > total 0
> > >
> > > sony:/home/akpm> showmount -e bix
> > > Export list for bix:
> > > / *
> > > /usr/src *
> > > /mnt/export *
> >
> > Yes, but what's your /etc/exports now? Not all options appear to showmount.
> >
> > Can you add "nohide" to the /usr/src and /mnt/export lines and "fsid=0" to the
> > / line if you don't currently have them and try again?
> >
> > > iirc, we decided this is related to the fs-cache infrastructure work which
> > > went into git-nfs. I think David can reproduce this?
> >
> > I'd only reproduced it with SELinux in enforcing mode.
> >
> > Under such conditions, unless there's a readdir on the root directory, the
> > subdirs under which exports exist will remain as incorrectly negative
> > dentries.
> >
> > The problem is a conjunction of circumstances:
> >
> > (1) nfs_lookup() has a shortcut in it that skips contact with the server if
> > we're doing a lookup with intent to create. This leaves an incorrectly
> > negative dentry if there _is_ actually an object on the server.
> >
> > (2) The mkdir procedure is aborted between the lookup() op and the mkdir() op
> > by SELinux (see vfs_mkdir()). Note that SELinux isn't the _only_ method
> > by which the abort can occur.
> >
> > (3) One of my patches correctly assigns the security label to the automounted
> > root dentry.
> >
> > (4) SELinux then aborts the automounter's mkdir() call because the automounter
> > does _not_ carry the correct security label to write to the NFS directory.
> >
> > (5) The incorrectly set up dentry from (1) remains because the the mkdir() op
> > is not invoked to set it right.
> >
> > The only bit I added was (3), but that's not the only circumstance in which
> > this can occur.
> >
> >
> > If, for example, I do "chmod a-w /" on the NFS server, I can see the same
> > effects on the client without the need for SELinux to put its foot in the door.
> > Automount does:
> >
> > [pid 3838] mkdir("/net", 0555) = -1 EEXIST (File exists)
> > [pid 3838] stat64("/net", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> > [pid 3838] mkdir("/net/trash", 0555) = -1 EEXIST (File exists)
> > [pid 3838] stat64("/net/trash", {st_mode=S_IFDIR|0555, st_size=1024, ...}) = 0
> > [pid 3838] mkdir("/net/trash/mnt", 0555) = -1 EACCES (Permission denied)
> >
> > And where I was listing the disputed directory, I see:
> >
> > [root@andromeda ~]# ls -lad /net/trash/usr/src
> > drwxr-xr-x 4 root root 1024 Aug 30 10:35 /net/trash/usr/src/
> > [root@andromeda ~]#
> >
> > which isn't what I'd expect. What I'd expect is:
> >
> > [root@andromeda ~]# ls -l /net/trash/usr/src
> > total 15
> > drwxr-xr-x 3 root root 1024 Aug 30 10:35 debug/
> > -rw-r--r-- 1 root root 0 Aug 16 10:01 hello
> > drwx------ 2 root root 12288 Aug 16 10:00 lost+found/
> > [root@andromeda ~]#
>
> One way to fix this is to simply not hash the dentry when we're doing
> the O_EXCL intent optimisation, but rather to only hash it _after_ we've
> successfully created the file on the server. Something like the attached
> patch ought to do it.
>
> Note, though, that this will not fix the autofs problem: autofs is
> trying to perform a totally unnecessary mkdir(), and is giving up when
> it is told that SELinux won't authorise that particular operation. This
> is clearly an autofs bug...
selinux is not involved in this senario.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
