linux-kernel - Re: [PATCH] NFS: Replace null dentries that appear in readdir's list [try #2]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0608202223220.29268@raven.themaw.net>
Date:	Sun, 20 Aug 2006 22:25:40 +0800 (WST)
From:	Ian Kent <raven@...maw.net>
To:	David Howells <dhowells@...hat.com>
cc:	Andrew Morton <akpm@...l.org>,
	Trond Myklebust <trond.myklebust@....uio.no>,
	linux-kernel@...r.kernel.org, aviro@...hat.com
Subject: Re: [PATCH] NFS: Replace null dentries that appear in readdir's list
 [try #2]

On Sun, 20 Aug 2006, David Howells wrote:

> Andrew Morton <akpm@...l.org> wrote:
> 
> > The funny-looking dentries in /net/bix have gone away.
> > 
> > But `ls -l /net/bix/usr/src' doesn't mount bix:/usr/src.
> 
> Yes, that I believe is due to the automounter program combined with that
> optimisation in the NFS client code.  *readdir* fixes the falsely negative
> dentry, but only if you _do_ a readdir of the parent directory, and only then
> if you read enough of the directory to locate the dodgy dentry.
> 
> This is normally only a problem if SELinux aborts the mkdir operation between
> calling the filesystem's lookup() op and the filesystem's mkdir() op, if the
> filesystem is written - as NFS is - to assume the the lookup() op _will_ be
> followed by a call to the mkdir() op whatever happens.  Unfortunately, with
> SELinux sticking its foot in the way, this no longer holds true, and the
> initial lookup _must_ properly instantiate the dentry it is given - and that
> means it must query the server in such a case.
> 
> That said, that will likely prevent autofs from being able to create arbitrary
> directories if the underlying security constraints don't let it.
> 
> There is another problem with autofs arbitrarily creating directory dentries
> in this manner: the automount program doesn't know whether the directory it is
> creating corresponds to a directory on the server - or whether it corresponds
> to a symbolic link...  The server _must_ be queried.
> 
> So, I think:
> 
>  (1) I have to change my patch again, and that I have to make nfs_lookup()
>      unconditionally query the server (comments Trond?), and
> 
>  (2) Ian has to patch the automounter to not attempt to mount undermounts
>      automatically - with the new in-NFS-client automounting code, this should
>      be unnecessary, except for when the an intervening directory is
>      inaccessible, and I'm not sure what you can do about that (Ian? Trond?)

I guess I knew this would with the nfs v4 mounting.

I don't have a server with v4 nested type mounts handy. How can I tell, 
from the output of the exports list, what I should leave alone?

Ian

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/