linux-kernel - Re: [PATCH 06/14] VFS: Introduce a superblock configuration context

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]

Date:   Thu, 11 May 2017 08:24:37 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     David Howells <dhowells@...hat.com>
Cc:     mszeredi@...hat.com, jlayton@...hat.com,
        linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 06/14] VFS: Introduce a superblock configuration context

On Wed, May 10, 2017 at 05:19:19PM +0100, David Howells wrote:
> + (*) struct mnt_namespace *mnt_ns
> +
> +     This is a subset of the namespaces in use by the invoking process.  This
> +     retains a ref on each namespace.  The subscribed namespaces may be
> +     replaced by the filesystem to reflect other sources, such as the parent
> +     mount superblock on an automount.

I don't think it's a good idea.  No comments on userns stuff, but what's
the situation when you want it to play with the real namespace?  Details,
please...

> + (*) int (*fill_super)(struct super_block *s, struct sb_config *sc);
> +
> +     This is available to be used by things like mount_ns_mc() that are called
> +     by ->mount() to transfer information/resources from the superblock configuration context to
> +     the superblock.

        Don't.  This kind of stuff can bloody well be an explicit callback.
Methods of that kind are trouble - we had that sort of PITA quite a few
times, and it had always been a headache when we eventually had to kill them
off.  Starting with ->read_inode(), if you remember that one...