linux-kernel - Re: BUG: Mount ignores mount options

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:   Sat, 11 Aug 2018 09:31:29 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     David Howells <dhowells@...hat.com>
Cc:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        viro@...iv.linux.org.uk,
        John Johansen <john.johansen@...onical.com>,
        Tejun Heo <tj@...nel.org>, selinux@...ho.nsa.gov,
        Paul Moore <paul@...l-moore.com>,
        Li Zefan <lizefan@...wei.com>, linux-api@...r.kernel.org,
        apparmor@...ts.ubuntu.com,
        Casey Schaufler <casey@...aufler-ca.com>, fenghua.yu@...el.com,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Eric Biggers <ebiggers@...gle.com>,
        linux-security-module@...r.kernel.org,
        Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        Johannes Weiner <hannes@...xchg.org>,
        Stephen Smalley <sds@...ho.nsa.gov>,
        tomoyo-dev-en@...ts.sourceforge.jp, cgroups@...r.kernel.org,
        torvalds@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, "Theodore Y. Ts'o" <tytso@....edu>,
        Miklos Szeredi <miklos@...redi.hu>
Subject: Re: BUG: Mount ignores mount options

> On Aug 11, 2018, at 12:29 AM, David Howells <dhowells@...hat.com> wrote:
> 
> Eric W. Biederman <ebiederm@...ssion.com> wrote:
> 
>>> Yes, I agree it would be nice to have, but it *doesn't* really need
>>> supporting right this minute, since what I have now oughtn't to break the
>>> current behaviour.
>> 
>> I am really reluctant to endorse anything that propagates the issues of
>> the current interface in the new mount interface.
> 
> Do realise that your problem cannot be solved through fsopen() until every
> filesystem is converted to the new fs_context-based sget() since the flag has
> to make it from the VFS through the filesystem to sget().
> 
> I'm reluctant to add this flag till that point until that time unless we error
> out if the flag is set against a legacy filesystem.
> 
> 

I don’t see why we need all this fancy “do the options match” stuff.  For the handful of filesystems (like NFS) that do something intelligent when multiple non-bind mount requests against the same underlying storage happen,  we can keep that behavior in the new API. For other filesystems that don’t have this feature, we should simply fail the request.

IOW I see so compelling reason to call sget() at all from the new API.  The only sort-of-legit use case I can think of is mounting more than one btrfs subvolume. But even that should probably not be done by asking the kernel to separately instantiate the filesystem.

As another way of looking at it: for a network filesystem, mounting the same target ip and path from two different Linux machines works, so mounting it twice from the same machine should also work.  But mounting the same underlying ext4 block device from two different Linux machines (using nbd, iscsi, etc) would be a catastrophe, so I see no reason that it needs to be supported if it’s two mounts from one machine.

The case folding example is interesting, and I think it should probably have a slightly different API. A program could open_tree a nocasefold mount and then make a request to create what is functionally a bind mount but with different options.

mount(8) will presumably just keep using mount(2).