linux-kernel - Re: [PATCH][RFC] NFS: Propagate 'fsc' mount option through automounts

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 14 Jul 2009 15:03:20 -0400
From:	Trond Myklebust <Trond.Myklebust@...app.com>
To:	David Howells <dhowells@...hat.com>
Cc:	steved@...hat.com, nfsv4@...ux-nfs.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH][RFC] NFS: Propagate 'fsc' mount option through
 automounts

On Tue, 2009-07-14 at 18:47 +0100, David Howells wrote:
> Trond Myklebust <Trond.Myklebust@...app.com> wrote:
> 
> > Why not just use the mount path as the default uniquifier?
> 
> Because:
> 
>  (1) Which mount path?  You're now constructing the mount tree in its own
>      private namespace.

The natural thing would be to use the mount path that is required to
locate the super block's root dentry on the server (i.e. the mount path
for sb->s_root).
In the private namespace (since that reflects the namespace of the
server, and hence mnt->mnt_root == sb->s_root) this mount path will
always be the same as the contents of mnt->mnt_devname. 

(In the local namespace, however, sb->s_root != mnt->mnt_root, and so
mnt->mnt_devname is fixed up to reflect that difference. See
nfs_fix_devname()...)

>  (2) Due to the new VFS-pathwalk-based mount, the uniquifier is applied to the
>      root mount only, and if modified to inherit, would be applied to every
>      automount subordinate to that, rather than just the actual subject of the
>      mount.
>
>  (3) Due to the new VFS-pathwalk-based mount and the private namespace, the
>      default uniquifier for all instances of any particular mount is always
>      the same.

...and is that sufficient? If it is, then fine, let's leave it...

>  (4) If we work around some how the mounts now getting their mount path from
>      the private namespace, there are still real namespaces, chroots and
>      root-pivots to contend with.

Real namespaces, chroots and root-pivots are all changes to the client
only. They do not change the server's namespace, and hence the mount
path is invariant.

     Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@...app.com
www.netapp.com
--
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/