From: Eric W. Biederman <hidden> Date: 2018-08-10 16:35:48
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.
Eric
# cat ~/bin/bdev-loop0.sh
#!/bin/sh
set -x
set -e
LOOP=loop0
dd if=/dev/zero bs=1024 count=1048576 of=$LOOP-file
losetup /dev/$LOOP $LOOP-file
mkfs.ext4 /dev/$LOOP
mkdir $LOOP-noacl-noquota-nouser_xattr
mount -t ext4 /dev/$LOOP -o "noacl,noquota,nouser_xattr" $LOOP-noacl-noquota-nouser_xattr
mkdir $LOOP-acl-quota-user_xattr
mount -t ext4 /dev/$LOOP -o "acl,quota,user_xattr" $LOOP-acl-quota-user_xattr
cat /proc/mounts | grep loop0
root@finagle:~# ~/bin/bdev-loop0.sh
+ set -e
+ LOOP=loop0
+ dd if=/dev/zero bs=1024 count=1048576 of=loop0-file
1048576+0 records in
1048576+0 records out
1073741824 bytes (1.1 GB) copied, 4.37645 s, 245 MB/s
+ losetup /dev/loop0 loop0-file
+ mkfs.ext4 /dev/loop0
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
65536 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=268435456
8 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 29 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
+ mkdir loop0-noacl-noquota-nouser_xattr
+ mount -t ext4 /dev/loop0 -o noacl,noquota,nouser_xattr loop0-noacl-noquota-nouser_xattr
+ mkdir loop0-acl-quota-user_xattr
+ mount -t ext4 /dev/loop0 -o acl,quota,user_xattr loop0-acl-quota-user_xattr
+ + grep loop0
cat /proc/mounts
/dev/loop0 /root/loop0-noacl-noquota-nouser_xattr ext4 rw,relatime,nouser_xattr,noacl 0 0
/dev/loop0 /root/loop0-acl-quota-user_xattr ext4 rw,relatime,nouser_xattr,noacl 0 0
From: David Howells <dhowells@redhat.com> Date: 2018-08-10 15:11:31
Eric W. Biederman [off-list ref] 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.
Yes. Since you *absolutely* *insist* on this being fixed *right* *now* *or*
*else*, I'm working up a set of additional patches to give userspace the
option of whether they want no sharing; sharing, but only with exactly the
same parameters; or to ignore the parameter differences and just accept
sharing of what's already already mounted (ie. the current behaviour).
The second option, however, is not trivial as it needs to compare the fs
contexts, including the LSM parameters. To make that work, I really need to
remove the old security_mnt_opts stuff - which means I need to port btrfs to
the new context stuff.
We discussed this yesterday, and I proposed a solution, and I'm working on it.
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.
David
From: Andy Lutomirski <luto@amacapital.net> Date: 2018-08-10 17:06:29
On Aug 10, 2018, at 7:05 AM, Eric W. Biederman [off-list ref] 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.
To make sure I understand correctly: the problem is that the second mount ignored the options because the device was already mounted, right?
For the new API, I think the only remotely sane approach is to refuse to mount or init or whatever you call it an already mounted bdev. If user code genuinely needs to bind-mount an existing mount that is known only by its bdev, we can add a specific API just for that.
To make sure I understand correctly: the problem is that the second mount
ignored the options because the device was already mounted, right?
For the new API, I think the only remotely sane approach is to refuse to
mount or init or whatever you call it an already mounted bdev. If user code
genuinely needs to bind-mount an existing mount that is known only by its
bdev, we can add a specific API just for that.
I'm adding some flags to fsopen() to allow userspace to say whether it wants
no sharing, same parameters-only sharing or anything-goes sharing (as now).
I'm also adding a flag whereby userspace can forbid anyone else from sharing a
new superblock it has just set up.
David
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.
Eric
This might be related to a problem that syzbot is failing to reproduce a problem.
https://groups.google.com/forum/#!msg/syzkaller-bugs/R03vI7RCVco/0PijCTrcCgAJ
syzbot found a reproducer, and the reproducer was working until next-20180803.
But the reproducer is failing to reproduce this problem in next-20180806 despite
there is no mm related change between next-20180803 and next-20180806.
Therefore, I suspect that the reproducer is no longer working as intended. And
there was parser change (David Howells' patch) between next-20180803 and next-20180806.
I'm waiting for response from David Howells...
From: Al Viro <viro@ZenIV.linux.org.uk> Date: 2018-08-10 17:46:55
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.
From: Al Viro <viro@ZenIV.linux.org.uk> Date: 2018-08-10 17:54:50
On Fri, Aug 10, 2018 at 07:36:17AM -0700, Andy Lutomirski wrote:
quoted
On Aug 10, 2018, at 7:05 AM, Eric W. Biederman [off-list ref] 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.
To make sure I understand correctly: the problem is that the second mount ignored the options because the device was already mounted, right?
For the new API, I think the only remotely sane approach is to refuse to mount or init or whatever you call it an already mounted bdev. If user code genuinely needs to bind-mount an existing mount that is known only by its bdev, we can add a specific API just for that.
First of all, that does NOT belong anywhere other than fs itself.
Example: NFS. Not every attempt to mount something leads to creation
of new fs instance; moreover, whether it will or not can't be predicted
in general.
PS: for pity sake, fix your MUA; 270-character lines are way over the
top.
From: "Theodore Y. Ts'o" <tytso@mit.edu> Date: 2018-08-10 18:09:51
On Fri, Aug 10, 2018 at 04:11:31PM +0100, David Howells wrote:
Yes. Since you *absolutely* *insist* on this being fixed *right* *now* *or*
*else*, I'm working up a set of additional patches to give userspace the
option of whether they want no sharing; sharing, but only with exactly the
same parameters; or to ignore the parameter differences and just accept
sharing of what's already already mounted (ie. the current behaviour).
But there's no way to support "no sharing", at least not in the
general case. A file system can only be mounted once, and without
file system support, there's no way for a file system to be mounted
with the bsddf or minixdf mount simultaneously.
Even *with* file system support, there's no way today for the VFS to
keep track of whether a pathname resolution came through one
mountpoint or another, so I can't do something like this:
mount /dev/sdXX -o casefold /android-data
mount /dev/sdXX -o nocasefold /android-data-2
Which is a pity, since if we could we could much more easily get rid
of the horror which is Android's wrapfs...
So if the file system has been mounted with one set of mount options,
and you want to try to mount it with a conflicting set of mount
options and you don't want it to silently ignore the mount options,
the *only* thing we can today is to refuse the mount and return an
error.
I'm not sure Eric would really consider that an improvement for the
container use case....
- Ted
P.S. And as Al has pointed out, this would require special, per-file
system support to determine whether the mount options are conflicting
or not....
From: David Howells <dhowells@redhat.com> Date: 2018-08-10 18:24:29
Theodore Y. Ts'o [off-list ref] wrote:
Even *with* file system support, there's no way today for the VFS to
keep track of whether a pathname resolution came through one
mountpoint or another, so I can't do something like this:
Ummm... Isn't that encoded in the vfsmount pointer in struct path?
However, the case folding stuff - is that a superblockism of a mountpointism?
So if the file system has been mounted with one set of mount options,
and you want to try to mount it with a conflicting set of mount
options and you don't want it to silently ignore the mount options,
the *only* thing we can today is to refuse the mount and return an
error.
With fsopen() there is the option to have the filesystem and the LSM attempt
to compare the non-key[*] mount options and reject the attempt to share if
they differ in any way.
David
[*] sget lookup keys, that is.
On Fri, Aug 10, 2018 at 04:11:31PM +0100, David Howells wrote:
quoted
Yes. Since you *absolutely* *insist* on this being fixed *right* *now* *or*
*else*, I'm working up a set of additional patches to give userspace the
option of whether they want no sharing; sharing, but only with exactly the
same parameters; or to ignore the parameter differences and just accept
sharing of what's already already mounted (ie. the current behaviour).
But there's no way to support "no sharing", at least not in the
general case. A file system can only be mounted once, and without
file system support, there's no way for a file system to be mounted
with the bsddf or minixdf mount simultaneously.
Even *with* file system support, there's no way today for the VFS to
keep track of whether a pathname resolution came through one
mountpoint or another, so I can't do something like this:
mount /dev/sdXX -o casefold /android-data
mount /dev/sdXX -o nocasefold /android-data-2
Which is a pity, since if we could we could much more easily get rid
of the horror which is Android's wrapfs...
So if the file system has been mounted with one set of mount options,
and you want to try to mount it with a conflicting set of mount
options and you don't want it to silently ignore the mount options,
the *only* thing we can today is to refuse the mount and return an
error.
I'm not sure Eric would really consider that an improvement for the
container use case....
- Ted
P.S. And as Al has pointed out, this would require special, per-file
system support to determine whether the mount options are conflicting
or not....
This extends to LSMs that support mount options (SELinux and Smack)
as well.
From: "Theodore Y. Ts'o" <tytso@mit.edu> Date: 2018-08-10 18:44:53
On Fri, Aug 10, 2018 at 04:53:58PM +0100, David Howells wrote:
Theodore Y. Ts'o [off-list ref] wrote:
quoted
Even *with* file system support, there's no way today for the VFS to
keep track of whether a pathname resolution came through one
mountpoint or another, so I can't do something like this:
Ummm... Isn't that encoded in the vfsmount pointer in struct path?
Well, yes, and we do use this as a hack to make read-only bind mounts
work. But that's done as a special case, and it's for permissions
checking only.
The big problem is that there is single dentry cache object regardless
of which mount point was used to access it. So that makes it
impossible to support case folding as a mount-pointism.
However, the case folding stuff - is that a superblockism of a mountpointism?
It's a superblock-ism. As far as I know the *only* thing that we can
support as a mount-pointism is the ro flag, and that's handled as a
special case, and only if the original superblock was mounted
read/write. ey That was my point; aside from the ro flag, we can't
support any other mount options as a per-mount point thing, so the
only thing we can do is to fail the mount if there are conflicting
mount options. 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.
So before you put in lots of work to support rejecting the attmpted
mount if the mount options conflict, are we sure people will actually
find this to be useful? Because it's not only fsopen() work for you,
but each file system is going to have to implement new functions to
answer the question "are these mount options conflicting or not?".
Are we sure it's worth the effort?
- Ted
From: Andy Lutomirski <luto@kernel.org> Date: 2018-08-10 22:38:39
On Fri, Aug 10, 2018 at 9:14 AM, Theodore Y. Ts'o [off-list ref] 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.
From: "Theodore Y. Ts'o" <tytso@mit.edu> Date: 2018-08-10 23:18:31
On Fri, Aug 10, 2018 at 01:06:54PM -0700, Andy Lutomirski wrote:
If the same block device is visible, with rw access, in two different
containers, I don't see any anything good can happen.
It's worse than that. I've fixed a lot of bugs which cause the kernel
to crash, and a few that might be levered into a privilege escalationh
attack, when you mount a maliciously corrupted file system using ext4.
I'm told told the security researcher filed similar reports with the
XFS community, and he was told, "that's what metadata checksums are
for; go away". Given how much time it takes to work with these
security researchers, I don't blame them.
But in light of that, I'd make a somewhat stronger statement. If you
let an untrusted container mount arbitrary block devices where they
have rw acccess to the underlying block device, nothing good can
happen. Period. :-)
Which is why I don't think the lack of being able to reject
"conflicting mount options" is really all that important. It
certainly shouldn't block the fsopen patch series. #1, it's a problem
we have today, and #2, I'm really not all sure supporting bind mounts
via specifying block device was ever a good idea to begin with. And
#3, while I've been fixing ext4 against security issues caused by
maliciously corrupted file system images, I'm still sure that allowing
untrusted containers access to mount *any* file system via a block
device for which they have r/w access is a Really Bad Idea.
It seems to me that the current approach mostly involves crossing our fingers.
From: "Theodore Y. Ts'o" <tytso@mit.edu> Date: 2018-08-10 23:54:47
On Fri, Aug 10, 2018 at 03:12:34PM -0700, Darrick J. Wong wrote:
Hey now, there was a little more nuance to it than that[1][2]. The
complaint in the first instance had much more to do with breaking
existing V4 filesystems by adding format requirements that mkfs didn't
know about when the filesystem was created. Yes, you can create V4
filesystems that will hang the system if the log was totally unformatted
and metadata updates are made, but OTOH it's fairly obvious when that
happens, you have to be root to mount a disk filesystem, and we try to
avoid breaking existing users.
I wasn't thinking about syzbot reports; I've largely written them off
as far as file system testing is concerned, but rather Wen Xu at
Georgia Tech, who is much more reasonable than Dmitry, and has helpeyd
me out a lot; and has complained that the XFS folks haven't been
engaging with him.
In either case, both security researchers are fuzzing file system
images, and then fixing the checksums, and discovering that this can
lead to kernel crashes, and in a few cases, buffer overruns that can
lead to potential privilege escalations. Wen can generate reports
faster than syzbot, but at least he gives me file system images (as
opposed to having to dig them out of syzbot repro C files) and he
actually does some analysis and explains what he thinks is going on.
I don't think anyone was claiming that format requirements should be
added to ext4 or xfs file systems. But rather, that kernel code
should be made more robust against maliciously corrupted file system
images that have valid checksums. I've been more willing to work with
Wen; Dave has expressed the opinion that these are not realistic bug
reports, and since only root can mount file systems, it's not high
priority.
The reason why I bring this up here is that in container land, there
are those who believe that "container root" should be able to mount
file systems, and if the "container root" isn't trusted, the fact that
the "container root" can crash the host kernel, or worse, corrupt the
host kernel and break out of the container as a result, that would be
sad.
I was pretty sure most file system developers are on the same page
that allowing untrusted "container roots" the ability to mount
arbitrary block device file systems is insanity. Whether or not we
try to fix these sorts of bugs submitted by security researchers. :-)
- Ted
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
From: Darrick J. Wong <hidden> Date: 2018-08-11 00:45:16
On Fri, Aug 10, 2018 at 04:46:39PM -0400, Theodore Y. Ts'o wrote:
On Fri, Aug 10, 2018 at 01:06:54PM -0700, Andy Lutomirski wrote:
quoted
If the same block device is visible, with rw access, in two different
containers, I don't see any anything good can happen.
It's worse than that. I've fixed a lot of bugs which cause the kernel
to crash, and a few that might be levered into a privilege escalationh
attack, when you mount a maliciously corrupted file system using ext4.
I'm told told the security researcher filed similar reports with the
XFS community, and he was told, "that's what metadata checksums are
for; go away".
Hey now, there was a little more nuance to it than that[1][2]. The
complaint in the first instance had much more to do with breaking
existing V4 filesystems by adding format requirements that mkfs didn't
know about when the filesystem was created. Yes, you can create V4
filesystems that will hang the system if the log was totally unformatted
and metadata updates are made, but OTOH it's fairly obvious when that
happens, you have to be root to mount a disk filesystem, and we try to
avoid breaking existing users.
XFS developers have been and will continue to examine security problems
when they are brought to our attention and strengthen validation as
needed to minimize the risk of incorrect behaviors, but filesystems are
complex machines, complex machinery is risky, and we arbitrate some of
that risk by requiring administrators to elect to mount an XFS.
Given how much time it takes to work with these security researchers,
I don't blame them.
But in light of that, I'd make a somewhat stronger statement. If you
let an untrusted container mount arbitrary block devices where they
have rw acccess to the underlying block device, nothing good can
happen. Period. :-)
Which is why I don't think the lack of being able to reject
"conflicting mount options" is really all that important. It
certainly shouldn't block the fsopen patch series. #1, it's a problem
we have today, and #2, I'm really not all sure supporting bind mounts
via specifying block device was ever a good idea to begin with. And
#3, while I've been fixing ext4 against security issues caused by
maliciously corrupted file system images, I'm still sure that allowing
untrusted containers access to mount *any* file system via a block
device for which they have r/w access is a Really Bad Idea.
quoted
It seems to me that the current approach mostly involves crossing our fingers.
From: Darrick J. Wong <hidden> Date: 2018-08-11 03:11:57
On Fri, Aug 10, 2018 at 07:54:47PM -0400, Theodore Y. Ts'o wrote:
On Fri, Aug 10, 2018 at 03:12:34PM -0700, Darrick J. Wong wrote:
quoted
Hey now, there was a little more nuance to it than that[1][2]. The
complaint in the first instance had much more to do with breaking
existing V4 filesystems by adding format requirements that mkfs didn't
know about when the filesystem was created. Yes, you can create V4
filesystems that will hang the system if the log was totally unformatted
and metadata updates are made, but OTOH it's fairly obvious when that
happens, you have to be root to mount a disk filesystem, and we try to
avoid breaking existing users.
I wasn't thinking about syzbot reports; I've largely written them off
as far as file system testing is concerned, but rather Wen Xu at
Georgia Tech, who is much more reasonable than Dmitry, and has helpeyd
me out a lot; and has complained that the XFS folks haven't been
engaging with him.
Ahh, ok. Yes, Wen has been easier to work with, and gives out
filesystem images. Hm, I'll go comb the bugzilla again...
In either case, both security researchers are fuzzing file system
images, and then fixing the checksums, and discovering that this can
lead to kernel crashes, and in a few cases, buffer overruns that can
lead to potential privilege escalations. Wen can generate reports
faster than syzbot, but at least he gives me file system images (as
opposed to having to dig them out of syzbot repro C files) and he
actually does some analysis and explains what he thinks is going on.
(FWIW I tried to figure out how to add fs image dumping to syzbot and
whoah that was horrifying.
I don't think anyone was claiming that format requirements should be
added to ext4 or xfs file systems. But rather, that kernel code
should be made more robust against maliciously corrupted file system
images that have valid checksums. I've been more willing to work with
Wen; Dave has expressed the opinion that these are not realistic bug
reports, and since only root can mount file systems, it's not high
priority.
I don't think they're high priority either, but they're at least worth
/some/ attention.
The reason why I bring this up here is that in container land, there
are those who believe that "container root" should be able to mount
file systems, and if the "container root" isn't trusted, the fact that
the "container root" can crash the host kernel, or worse, corrupt the
host kernel and break out of the container as a result, that would be
sad.
I was pretty sure most file system developers are on the same page
that allowing untrusted "container roots" the ability to mount
arbitrary block device file systems is insanity.
Agreed.
Whether or not we try to fix these sorts of bugs submitted by security
researchers. :-)
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
At the raw level there are lots of use cases involving high performance
data capture, media streaming and the like.
At the file system layer you can use GFS2 for example.
So there are cases where it's possible. There are even cases where it's
actually useful at the filesystem level although not many I agree.
Alan
From: Al Viro <viro@ZenIV.linux.org.uk> Date: 2018-08-13 17:29:47
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.
From: James Morris <jmorris@namei.org> Date: 2018-08-13 19:00:41
On Mon, 13 Aug 2018, Al Viro wrote:
On Mon, Aug 13, 2018 at 09:48:53AM -0700, Andy Lutomirski wrote:
quoted
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.
Coincidentally, this was also the model for Linux capabilities.
--
James Morris
[off-list ref]
On Mon, Aug 13, 2018 at 09:48:53AM -0700, Andy Lutomirski wrote:
quoted
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.
Coincidentally, this was also the model for Linux capabilities.
Linux capabilities are POSIX capabilities which are modeled closely
to accommodate the historical behavior manifest in the P1003.1 specification.
So except for (c), (f) and (k) you can use this characterization.
On a slightly more serious note, there's a lot of Linux, mount semantics
included, that have grow organically and that aren't quite up to the
usage models they are being applied to. I applaud David's work in part
because it may make it possible to accommodate more of those cases going
forward.
From: Andy Lutomirski <luto@kernel.org> Date: 2018-08-13 19:32:19
On Mon, Aug 13, 2018 at 9:35 AM, Alan Cox [off-list ref] wrote:
quoted
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
At the raw level there are lots of use cases involving high performance
data capture, media streaming and the like.
At the file system layer you can use GFS2 for example.
Ugh. I even thought of this case, and I should have been a bit more precise:
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.
From: "Serge E. Hallyn" <serge@hallyn.com> Date: 2018-08-16 02:24:17
Quoting James Morris (jmorris@namei.org):
On Mon, 13 Aug 2018, Al Viro wrote:
quoted
On Mon, Aug 13, 2018 at 09:48:53AM -0700, Andy Lutomirski wrote:
quoted
quoted
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.
Coincidentally, this was also the model for Linux capabilities.
But maybe we want to split the stray dogs up by breed.