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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <6404.1247593654@redhat.com>
Date:	Tue, 14 Jul 2009 18:47:34 +0100
From:	David Howells <dhowells@...hat.com>
To:	Trond Myklebust <Trond.Myklebust@...app.com>
Cc:	dhowells@...hat.com, steved@...hat.com, nfsv4@...ux-nfs.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH][RFC] NFS: Propagate 'fsc' mount option through automounts

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.

 (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.

 (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.

> > +	target->options = source->options;
> 
> BTW: Why does fscache require a private flag field?

I thought it best to avoid touching nfs_server::flags as that is at least
partially visible to userspace.

> > +	struct nfs_parsed_mount_data parsed_data = { .fscache_uniq = NULL, };
> 
> Rather than wasting all this space on the stack, how about just changing
> the second argument of nfs_fscache_get_super_cookie()? You only use the
> pointer to data->fscache_uniq.

Yeah, that's probably wise.

Actually, I don't really want to get this data via mount at all (as there are
automounts to locally configure for caching).

David
--
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/