linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: viro@ZenIV.linux.org.uk (Al Viro)
To: linux-security-module@vger.kernel.org
Subject: BUG: Mount ignores mount options
Date: Fri, 10 Aug 2018 16:16:06 +0100	[thread overview]
Message-ID: <20180810151606.GA6515@ZenIV.linux.org.uk> (raw)
In-Reply-To: <87d0uqpba5.fsf@xmission.com>

On Fri, Aug 10, 2018 at 09:05:22AM -0500, Eric W. Biederman wrote:
> 
> There is a serious problem with mount options today that fsopen does not
> address.  The problem is that mount options are ignored for block based
> filesystems, and any other type of filesystem that follows the same
> pattern.
> 
> The script below demonstrates this bug.  Showing this bug can cause the
> ext4 "acl" "quota" and "user_xattr" options to be silently ignored.
> 
> fsopen has my nack until it addresses this issue.
> 
> I don't know if we can fix this in the context of sys_mount.  But we if
> we are redoing the option parsing of how we mount filesystems this needs
> to be fixed before we start worrying about bug compatibility.
> 
> Hopefully this report is simple and clear enough that we can at least
> agree on the problem.

Sure, it is simple.  So's the solution: MNT_USERNS_SPECIAL_SEMANTICS that
would get passed to filesystems, so that Eric would be able to implement
his mount(2)-incompatible behaviour at leisure, without worrying about
compatibility issues.

Does that address your complaint?  Because one thing we are not going
to do is changing mount(2) behaviour.  Reason: userland-visible
behaviour of hell knows how many local scripts.  Another thing that
is flat-out not feasible is some kind of blanket "compare options"
stuff; it *can* be done as helpers to be used by filesystem when
it sees that new flag, but it's simply not going to work at the
fs-independent level.  Trivial example with the same ext4:
mount /dev/sda1 /mnt/a -o bsddf vs. mount /dev/sda1 /mnt/b
ext4 can tell that these are the same.  syscall itself has no
clue.  What's more, it's not just explicitly spelled default
options - it's the stuff that has more than one form.  And while
we are at it, the things like two NFS mounts of different trees
from the same server; they might or might not get the same superblock.
Depending upon the options.

Convenience helper that would allow ext4 to compare options and reject
the incompatible mount?  Not sure how much ext4-specific knowledge
would have to go in it, but if you can come up with one - more power
to you.  But the decision to use it *must* be ext4-specific.  Because
for e.g. NFS such thing as -o fsid=..., while certainly a part of
options, has a very different meaning - it's "use a separate fs instance"
(and let the server deal with coherency issues on its end).

Decision to use sget() (and the way it's used) is up to filesystem.
We *can't* lift that into syscall.  Not without breaking the fuck out
of existing behaviour.

Having something like a second callback for mount_bdev() that would
be called when we'd found an existing instance for the same block
device?  Sure, no problem.  Having a helper for doing such comparison
that would work in enough cases to bother, so that different fs
could avoid boilerplate in that callback?  Again, more power to you.

But I don't see what the hell does that have to the syscall interface.

  parent reply	other threads:[~2018-08-10 15:16 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-01 15:23 [PATCH 00/33] VFS: Introduce filesystem context [ver #11] David Howells
2018-08-01 15:24 ` [PATCH 08/33] vfs: Add LSM hooks for the new mount API " David Howells
2018-08-01 20:50   ` James Morris
2018-08-01 22:53   ` David Howells
2018-08-01 15:25 ` [PATCH 09/33] selinux: Implement the new mount API LSM hooks " David Howells
2018-08-01 15:25 ` [PATCH 10/33] smack: Implement filesystem context security " David Howells
2018-08-01 15:25 ` [PATCH 11/33] apparmor: Implement security hooks for the new mount API " David Howells
2018-08-01 15:25 ` [PATCH 12/33] tomoyo: " David Howells
2018-08-10 14:05 ` BUG: Mount ignores mount options Eric W. Biederman
2018-08-10 14:36   ` Andy Lutomirski
2018-08-10 15:17     ` Eric W. Biederman
2018-08-10 15:24     ` Al Viro
2018-08-10 15:11   ` Tetsuo Handa
2018-08-10 15:13   ` David Howells
2018-08-10 15:16   ` Al Viro [this message]
2018-08-11  1:05     ` Eric W. Biederman
2018-08-11  1:46       ` Theodore Y. Ts'o
2018-08-11  4:48         ` Eric W. Biederman
2018-08-11 17:47           ` Casey Schaufler
2018-08-15  4:03             ` Eric W. Biederman
2018-08-11  1:58       ` Al Viro
2018-08-11  2:17         ` Al Viro
2018-08-11  4:43           ` Eric W. Biederman
2018-08-13 12:54         ` Miklos Szeredi
2018-08-10 15:11 ` David Howells
2018-08-10 15:39   ` Theodore Y. Ts'o
2018-08-10 15:55     ` Casey Schaufler
2018-08-10 16:11     ` David Howells
2018-08-10 18:00     ` Eric W. Biederman
2018-08-10 15:53   ` David Howells
2018-08-10 16:14     ` Theodore Y. Ts'o
2018-08-10 20:06       ` Andy Lutomirski
2018-08-10 20:46         ` Theodore Y. Ts'o
2018-08-10 22:12           ` Darrick J. Wong
2018-08-10 23:54             ` Theodore Y. Ts'o
2018-08-11  0:38               ` Darrick J. Wong
2018-08-11  1:32                 ` Eric W. Biederman
2018-08-13 16:35         ` Alan Cox
2018-08-13 16:48           ` Andy Lutomirski
2018-08-13 17:29             ` Al Viro
2018-08-13 19:00               ` James Morris
2018-08-13 19:20                 ` Casey Schaufler
2018-08-15 23:29                 ` Serge E. Hallyn
2018-08-11  0:28       ` Eric W. Biederman
2018-08-11  1:19   ` Eric W. Biederman
2018-08-11  7:29   ` David Howells
2018-08-11 16:31     ` Andy Lutomirski
2018-08-11 16:51       ` Al Viro
2018-08-15 16:31 ` Should we split the network filesystem setup into two phases? David Howells
2018-08-15 16:51   ` Andy Lutomirski
2018-08-16  3:51   ` Steve French
2018-08-16  5:06   ` Eric W. Biederman
2018-08-16 16:24     ` Steve French
2018-08-16 17:21       ` Eric W. Biederman
2018-08-16 17:23       ` Aurélien Aptel
2018-08-16 18:36         ` Steve French
2018-08-17 23:11     ` Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180810151606.GA6515@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-security-module@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).