From: viro@ZenIV.linux.org.uk (Al Viro)
To: linux-security-module@vger.kernel.org
Subject: Should we split the network filesystem setup into two phases?
Date: Sat, 18 Aug 2018 00:11:31 +0100 [thread overview]
Message-ID: <20180817231131.GI6515@ZenIV.linux.org.uk> (raw)
In-Reply-To: <87pnyiew8x.fsf@xmission.com>
On Thu, Aug 16, 2018 at 12:06:06AM -0500, Eric W. Biederman wrote:
> So I don't think we can completely abandon the option for filesystems
> to always create a new filesystem instance when mount(8) is called.
Huh? If filesystem wants to create a new instance on each ->mount(),
it can bloody well do so. Quite a few do - if that fs can handle
that, more power to it.
The problem is what to do with filesystems that *can't* do that.
You really, really can't have two ext4 (or xfs, etc.) instances over
the same device at the same time. Cache coherency, locking, etc.
will kill you.
And that's not to mention the joy of defining the semantics of
having the same ext4 mounted with two logs at the same time ;-)
I've seen "reject unless the options are compatible/identical/whatever",
but that ignores the real problem with existing policy. It's *NOT*
"I've mounted this and got an existing instance with non-matching
options". That's a minor annoyance (and back when that decision
had been made, mount(2) was very definitly root-only). The real
problem is different and much worse - it's remount.
I have asked to mount something and it had already been mounted,
with identical options. OK, so what happens if I do mount -o remount
on my instance? *IF* we are operating in the "only sysadmin can
mount new filesystems", it's not a big deal - there are already
lots of ways you can shoot yourself in the foot and mount(2) is
certainly a powerful one. But if we get to "Joe R. Luser can do
it in his container", we have a big problem.
Decision back then had been mostly for usability reasons - it was
back in 2001 (well before the containermania, userns or anything
of that sort) and it was more about "how many hoops does one have
to jump through to get something mounted, assuming the sanity of
sysadmin doing that?". If *anything* like userns had been a concern
back then, it probably would've been different. However, it's
17 years too late and if anyone has a functional TARDIS, I can
easily think of better uses for it...
prev parent reply other threads:[~2018-08-17 23:11 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
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 [this message]
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=20180817231131.GI6515@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).