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: Mon, 13 Aug 2018 18:29:47 +0100	[thread overview]
Message-ID: <20180813172947.GS6515@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CALCETrXvtSLjwx0swXo5g-vU3PmF-_6J6j1a_2pAba7bhzO9QQ@mail.gmail.com>

On Mon, Aug 13, 2018 at 09:48:53AM -0700, Andy Lutomirski wrote:

> I would consider the GFS2 case to be essentially equivalent to the NFS
> case.  I think we can probably divide all the filesystems into three
> or four types:
> 
> pseudo file systems: Multiple instantiations of the same fs driver
> pointing at the same backing store give separate filesystems.  (Same
> backing store includes the case where there isn't any backing store.)
> tmpfs is an example.  This isn't particularly interesting.
> 
> network-like file systems: Multiple instantiations of the same fs
> driver pointing at the same backing store are expected.  This includes
> NFS, GFS2, AFS, CIFS, etc.  This is only really interesting to the
> extent that, if the fs driver internally wants to share state between
> multiple instantiations, it should be smart enough to make sure the
> options are compatible or that it can otherwise handle mismatched
> options correctly.  NFS does this right.
> 
> non-network-like filesystems: There are complicated ones like btrfs
> and ZFS and simple ones like ext4.  In either case, multiple totally
> separate instantiations of the driver sharing the backing store will
> lead to corruption.  In cases like ext4, we seem to support it for
> legacy reasons, because we're afraid that there are scripts that try
> to mount the same block device more than once, and I think the new API
> has no need to support this.  In cases like btrfs, we also seem to
> support multiple user requests for "mounts" with the same underlying
> block devices because we need it for full functionality.  But I think
> this is because our API is wrong.
> 
> Are there cases I'm missing?  It sounds like the API could be improved
> to fully model the last case, and everything will work nicely.

	You know, that's starting to remind of this little gem of Borges:
http://www.alamut.com/subj/artiface/language/johnWilkins.html
Especially the delightful (fake) quote contained in there:
[...] it is written that the animals are divided into:
	(a) belonging to the emperor,
	(b) embalmed,
	(c) tame,
	(d) sucking pigs,
	(e) sirens,
	(f) fabulous,
	(g) stray dogs,
	(h) included in the present classification,
	(i) frenzied,
	(j) innumerable,
	(k) drawn with a very fine camelhair brush,
	(l) et cetera,
	(m) having just broken the water pitcher,
	(n) that from a long way off look like flies.

  reply	other threads:[~2018-08-13 17:29 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 [this message]
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=20180813172947.GS6515@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).