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]

Message-ID: <CALCETrXC8Z-q+PzzqMC-McA7UdmFubVcs2dVsT0Dt+GbSqjF5A@mail.gmail.com>
Date:   Fri, 10 Aug 2018 13:06:54 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     "Theodore Y. Ts'o" <tytso@....edu>,
        David Howells <dhowells@...hat.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        John Johansen <john.johansen@...onical.com>,
        Tejun Heo <tj@...nel.org>, SELinux-NSA <selinux@...ho.nsa.gov>,
        Paul Moore <paul@...l-moore.com>,
        Li Zefan <lizefan@...wei.com>,
        Linux API <linux-api@...r.kernel.org>,
        apparmor@...ts.ubuntu.com,
        Casey Schaufler <casey@...aufler-ca.com>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Eric Biggers <ebiggers@...gle.com>,
        LSM List <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,
        "open list:CONTROL GROUP (CGROUP)" <cgroups@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Miklos Szeredi <miklos@...redi.hu>
Subject: Re: BUG: Mount ignores mount options

On Fri, Aug 10, 2018 at 9:14 AM, Theodore Y. Ts'o <tytso@....edu> wrote:
> And I'm not really sure it helps the container use
> case, since the whole point is they want their "guest" to be able to
> blithely run "mount /dev/sda1 -o noxattr /mnt" and not worry about the
> fact that in some other container, someone had run "mount /dev/sda1 -o
> xattr /mnt".  But having the second mount fail because of conflicting
> mount option breaks the illusion that containers are functionally as
> rich as VM's.

If the same block device is visible, with rw access, in two different
containers, I don't see any anything good can happen.  Sure, with the
current somewhat erratic semantics of mount(2), something kind of sort
of reasonable happens if they both mount it.  But if one or both of
them try to use, say, tune2fs or fsck, it's not going to go well.  And
a situation where they mount with different options and the result
depends on the order of the mounts is just plain bad.

I see four sane ways to deal with this:

1. Don't put the block device in the container at all.  The container
manager mounts it.

2. Use seccomp or a similar mechanism to intercept and emulate the
mount request.

3. Teach the filesystem driver to do something sensible.  This will
inherently be per-fs, and probably involves some serious magic or
allowing filesystem-specific vfsmount options.

4. Introduce a concept of a special kind of fake block device that
refers to an existing superblock, doesn't allow direct read or write,
and does the right thing when mounted.  Not obviously worth the
effort.

It seems to me that the current approach mostly involves crossing our fingers.