David Howells [off-list ref] writes:
Eric W. Biederman [off-list ref] wrote:
quoted
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.
I repeated this because after some comments from Al on IRC yesterday
and Miklos's email replay. It appeared clear that I had not specified
why my issue was clearly enough for people reading the thread to
understand the problem that I see.
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.
I am really reluctant to endorse anything that propagates the issues of
the current interface in the new mount interface.
Eric
Eric W. Biederman [off-list ref] wrote:
quoted
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.
I am really reluctant to endorse anything that propagates the issues of
the current interface in the new mount interface.
Do realise that your problem cannot be solved through fsopen() until every
filesystem is converted to the new fs_context-based sget() since the flag has
to make it from the VFS through the filesystem to sget().
I'm reluctant to add this flag till that point until that time unless we error
out if the flag is set against a legacy filesystem.
David
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
On Aug 11, 2018, at 12:29 AM, David Howells [off-list ref] wrote:
Eric W. Biederman [off-list ref] wrote:
quoted
quoted
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.
I am really reluctant to endorse anything that propagates the issues of
the current interface in the new mount interface.
Do realise that your problem cannot be solved through fsopen() until every
filesystem is converted to the new fs_context-based sget() since the flag has
to make it from the VFS through the filesystem to sget().
I'm reluctant to add this flag till that point until that time unless we error
out if the flag is set against a legacy filesystem.
I don’t see why we need all this fancy “do the options match” stuff. For the handful of filesystems (like NFS) that do something intelligent when multiple non-bind mount requests against the same underlying storage happen, we can keep that behavior in the new API. For other filesystems that don’t have this feature, we should simply fail the request.
IOW I see so compelling reason to call sget() at all from the new API. The only sort-of-legit use case I can think of is mounting more than one btrfs subvolume. But even that should probably not be done by asking the kernel to separately instantiate the filesystem.
As another way of looking at it: for a network filesystem, mounting the same target ip and path from two different Linux machines works, so mounting it twice from the same machine should also work. But mounting the same underlying ext4 block device from two different Linux machines (using nbd, iscsi, etc) would be a catastrophe, so I see no reason that it needs to be supported if it’s two mounts from one machine.
The case folding example is interesting, and I think it should probably have a slightly different API. A program could open_tree a nocasefold mount and then make a request to create what is functionally a bind mount but with different options.
mount(8) will presumably just keep using mount(2).
On Sat, Aug 11, 2018 at 09:31:29AM -0700, Andy Lutomirski wrote:
I don’t see why we need all this fancy “do the options match” stuff. For the handful of filesystems (like NFS) that do something intelligent when multiple non-bind mount requests against the same underlying storage happen, we can keep that behavior in the new API. For other filesystems that don’t have this feature, we should simply fail the request.
IOW I see so compelling reason to call sget() at all from the new API. The only sort-of-legit use case I can think of is mounting more than one btrfs subvolume. But even that should probably not be done by asking the kernel to separately instantiate the filesystem.
May I politely suggest the esteemed participants of that conversation
to RTFS? Yes, I know that it's less fun that talking about your
rather vague ideas of how the things (surely) work, but it just might
avoid the feats of idiocy like the above.
Andy, I don't know how to put it more plainly: read the fucking source.
Even grep would do. The same NFS you've granted (among the "handful"
of filesystems) an exception, *DOES* *CALL* *THE* *FUCKING* sget().
Yes, really. And in some obscure[1] cases (including the one mentioned
upthread) it does reuse a pre-existing superblock. For a very good
reason.
[1] such as, oh, mounting two filesystems from the same server with
default options - who would've ever thought of doing something so
perverted?
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor