* Re: BUG: Mount ignores mount options
From: Serge E. Hallyn @ 2018-08-15 23:29 UTC (permalink / raw)
To: James Morris
Cc: Al Viro, Andy Lutomirski, Alan Cox, Theodore Y. Ts'o,
David Howells, Eric W. Biederman, John Johansen, Tejun Heo,
SELinux-NSA, Paul Moore, Li Zefan, Linux API, apparmor,
Casey Schaufler, Fenghua Yu, Greg Kroah-Hartman, Eric Biggers,
LSM List, Tetsuo Handa, Johannes Weiner <hanne>
In-Reply-To: <alpine.LRH.2.21.1808140458040.23296@namei.org>
Quoting James Morris (jmorris@namei.org):
> On Mon, 13 Aug 2018, Al Viro wrote:
>
> > On Mon, Aug 13, 2018 at 09:48:53AM -0700, Andy Lutomirski wrote:
>
> > > 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.
^ permalink raw reply
* Re: Should we split the network filesystem setup into two phases?
From: Andy Lutomirski @ 2018-08-15 16:51 UTC (permalink / raw)
To: David Howells
Cc: trond.myklebust, anna.schumaker, sfrench, steved, viro, torvalds,
Eric W. Biederman, linux-api, linux-security-module,
linux-fsdevel, linux-kernel, linux-nfs, linux-cifs, linux-afs,
ceph-devel, v9fs-developer
In-Reply-To: <17763.1534350685@warthog.procyon.org.uk>
> On Aug 15, 2018, at 9:31 AM, David Howells <dhowells@redhat.com> wrote:
>
> Having just re-ported NFS on top of the new mount API stuff, I find that I
> don't really like the idea of superblocks being separated by communication
> parameters - especially when it might seem reasonable to be able to adjust
> those parameters.
>
> Does it make sense to abstract out the remote peer and allow (a) that to be
> configured separately from any superblocks using it and (b) that to be used to
> create superblocks?
>
> Note that what a 'remote peer' is would be different for different
> filesystems:
...
I think this looks rather nice. But maybe you should generalize the concept of “peer” so that it works for btrfs too. In the case where you mount two different subvolumes, you’re creating a *something*, and you’re then creating a filesystem that references it. It’s almost the same thing.
>
>
>
> fs = fsopen("nfs", 0);
> fsconfig(fs, FSCONFIG_SET_PEER, "peer.1", NULL, peer1);
As you mention below, this seems like it might have namespacing issues.
>
> In terms of alternative interfaces, I'm not sure how easy it would be to make
> it like cgroups where you go and create a dir in a special filesystem, say,
> "/sys/peers/nfs", because the peers records and names would have to be network
> namespaced. Also, it might make it more difficult to use to create a root fs.
>
> On the other hand, being able to adjust the peer configuration by:
>
> echo 71 >/sys/peers/nfs/server.home/timeo
>
> does have a certain appeal.
>
> Also, netlink might be the right option, but I'm not sure how you'd pin the
> resultant object whilst you make use of it.
>
My suggestion would be to avoid giving these things names at all. I think that referring to them by fd should be sufficient, especially if you allow them to be reopened based on a mount that uses them and allow them to get bind-mounted somewhere a la namespaces to make them permanent if needed.
> A further thought is that is it worth making this idea more general and
> encompassing non-network devices also? This would run into issues of some
> logical sources being visible across namespaces and but not others.
Indeed :)
It probably pays to rope a btrfs person into this discussion.
^ permalink raw reply
* Should we split the network filesystem setup into two phases?
From: David Howells @ 2018-08-15 16:31 UTC (permalink / raw)
To: trond.myklebust, anna.schumaker, sfrench, steved, viro
Cc: dhowells, torvalds, Eric W. Biederman, linux-api,
linux-security-module, linux-fsdevel, linux-kernel, linux-nfs,
linux-cifs, linux-afs, ceph-devel, v9fs-developer
In-Reply-To: <153313703562.13253.5766498657900728120.stgit@warthog.procyon.org.uk>
Having just re-ported NFS on top of the new mount API stuff, I find that I
don't really like the idea of superblocks being separated by communication
parameters - especially when it might seem reasonable to be able to adjust
those parameters.
Does it make sense to abstract out the remote peer and allow (a) that to be
configured separately from any superblocks using it and (b) that to be used to
create superblocks?
Note that what a 'remote peer' is would be different for different
filesystems:
(*) For NFS, it would probably be a named server, with address(es) attached
to the name. In lieu of actually having a name, the initial IP address
could be used.
(*) For CIFS, it would probably be a named server. I'm not sure if CIFS
allows an abstraction for a share that can move about inside a domain.
(*) For AFS, it would be a cell, I think, where the actual fileserver(s) used
are a matter of direction from the Volume Location server.
(*) For 9P and Ceph, I don't really know.
What could be configured? Well, addresses, ports, timeouts. Maybe protocol
level negotiation - though not being able to explicitly specify, say, the
particular version and minorversion on an NFS share would be problematic for
backward compatibility.
One advantage it could give us is that it might make it easier if someone asks
for server X to query userspace in some way for the default parameters for X
are.
What might this look like in terms of userspace? Well, we could overload the
new mount API:
peer1 = fsopen("nfs", FSOPEN_CREATE_PEER);
fsconfig(peer1, FSCONFIG_SET_NS, "net", NULL, netns_fd);
fsconfig(peer1, FSCONFIG_SET_STRING, "peer_name", "server.home");
fsconfig(peer1, FSCONFIG_SET_STRING, "vers", "4.2");
fsconfig(peer1, FSCONFIG_SET_STRING, "address", "tcp:192.168.1.1");
fsconfig(peer1, FSCONFIG_SET_STRING, "address", "tcp:192.168.1.2");
fsconfig(peer1, FSCONFIG_SET_STRING, "timeo", "122");
fsconfig(peer1, FSCONFIG_CMD_SET_UP_PEER, NULL, NULL, 0);
peer2 = fsopen("nfs", FSOPEN_CREATE_PEER);
fsconfig(peer2, FSCONFIG_SET_NS, "net", NULL, netns_fd);
fsconfig(peer2, FSCONFIG_SET_STRING, "peer_name", "server2.home");
fsconfig(peer2, FSCONFIG_SET_STRING, "vers", "3");
fsconfig(peer2, FSCONFIG_SET_STRING, "address", "tcp:192.168.1.3");
fsconfig(peer2, FSCONFIG_SET_STRING, "address", "udp:192.168.1.4+6001");
fsconfig(peer2, FSCONFIG_CMD_SET_UP_PEER, NULL, NULL, 0);
fs = fsopen("nfs", 0);
fsconfig(fs, FSCONFIG_SET_PEER, "peer.1", NULL, peer1);
fsconfig(fs, FSCONFIG_SET_PEER, "peer.2", NULL, peer2);
fsconfig(fs, FSCONFIG_SET_STRING, "source", "/home/dhowells", 0);
m = fsmount(fs, 0, 0);
[Note that Eric's oft-repeated point about the 'creation' operation altering
established parameters still stands here.]
You could also then reopen it for configuration, maybe by:
peer = fspick(AT_FDCWD, "/mnt", FSPICK_PEER);
or:
peer = fspick(AT_FDCWD, "nfs:server.home", FSPICK_PEER_BY_NAME);
though it might be better to give it its own syscall:
peer = fspeer("nfs", "server.home", O_CLOEXEC);
fsconfig(peer, FSCONFIG_SET_NS, "net", NULL, netns_fd);
...
fsconfig(peer, FSCONFIG_CMD_SET_UP_PEER, NULL, NULL, 0);
In terms of alternative interfaces, I'm not sure how easy it would be to make
it like cgroups where you go and create a dir in a special filesystem, say,
"/sys/peers/nfs", because the peers records and names would have to be network
namespaced. Also, it might make it more difficult to use to create a root fs.
On the other hand, being able to adjust the peer configuration by:
echo 71 >/sys/peers/nfs/server.home/timeo
does have a certain appeal.
Also, netlink might be the right option, but I'm not sure how you'd pin the
resultant object whilst you make use of it.
A further thought is that is it worth making this idea more general and
encompassing non-network devices also? This would run into issues of some
logical sources being visible across namespaces and but not others.
David
^ permalink raw reply
* Re: BUG: Mount ignores mount options
From: Eric W. Biederman @ 2018-08-15 4:03 UTC (permalink / raw)
To: Casey Schaufler
Cc: Theodore Y. Ts'o, Al Viro, David Howells, John Johansen,
Tejun Heo, selinux, Paul Moore, Li Zefan, linux-api, apparmor,
fenghua.yu, Greg Kroah-Hartman, Eric Biggers,
linux-security-module, Tetsuo Handa, Johannes Weiner,
Stephen Smalley, tomoyo-dev-en, cgroups, torvalds, linux-fsdevel,
linux-kernel, Miklos Szeredi <miklo>
In-Reply-To: <001a1608-d0fa-84c1-9c54-ae36df95fd89@schaufler-ca.com>
Casey Schaufler <casey@schaufler-ca.com> writes:
> Don't blame the filesystems for behaving as documented.
No. This behavior is not documented. At least I certainly don't see a
word about this in any of the man pages. Where does it say mounting a
filesystem will not honor it's mount options?
It is also rare enough in practice it is something it is reasonable to
expect people to be surprised by.
> The problem is not in the mount mechanism, it's in the way you want to
> abuse it.
I am not asking for this behavior. I am pointing out this behavior
exists. I am pointing out this behavior is harmful. I am asking we
stop doing this harmful thing in the new API where we don't have a
chance of breaking anything.
The place where this has bitten the hardest is someone wrote a script to
do something for Xen in a chroot. That script involved a chroot that
mounted devpts and in doing so happend to change the options of the main
/dev/pts. Which resulted in ptys created with /dev/ptmx outside the
chroot with the wrong permissions. That in turn caused several distros
to retain the ancient suid pt_chown binary from libc that the devpts
filesystem was built to make obsolete. As the world turned that
pt_chown binary could be confused into chowning the wrong pty if a pty
from a container was used.
The fix was to mount a new instance of devpts every time mount of devpts
is called. That simplified the code, and allowed pt_chown to be removed
permanently. The tricky bit was figuring out how keep /dev/ptmx
working. I wound up testing on every distribution I could think of to
ensure no one would notice the slightly changed behavior of the devpts
filesystem.
The behavior in other filesystems of ignoring the options instead of
changing them on the filesystem isn't quite as bad. But it still has
the potential for a lot of mischief.
Eric
^ permalink raw reply
* Re: [RFC PATCH v2 13/27] mm: Handle shadow stack page fault
From: Yu-cheng Yu @ 2018-08-14 21:28 UTC (permalink / raw)
To: Peter Zijlstra, Dave Hansen
Cc: x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, linux-kernel,
linux-doc, linux-mm, linux-arch, linux-api, Arnd Bergmann,
Andy Lutomirski, Balbir Singh, Cyrill Gorcunov, Florian Weimer,
H.J. Lu, Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz,
Nadav Amit, Oleg Nesterov, Pavel Machek, Ravi V. Shankar, Vedvyas
In-Reply-To: <20180711090656.GS2476@hirez.programming.kicks-ass.net>
On Wed, 2018-07-11 at 11:06 +0200, Peter Zijlstra wrote:
> On Tue, Jul 10, 2018 at 04:06:25PM -0700, Dave Hansen wrote:
> >
> > On 07/10/2018 03:26 PM, Yu-cheng Yu wrote:
> > >
> > > + if (is_shstk_mapping(vma->vm_flags))
> > > + entry = pte_mkdirty_shstk(entry);
> > > + else
> > > + entry = pte_mkdirty(entry);
> > > +
> > > + entry = maybe_mkwrite(entry, vma);
> > > if (ptep_set_access_flags(vma, vmf->address, vmf->pte,
> > > entry, 1))
> > > update_mmu_cache(vma, vmf->address, vmf->pte);
> > > pte_unmap_unlock(vmf->pte, vmf->ptl);
> > > @@ -2526,7 +2532,11 @@ static int wp_page_copy(struct vm_fault
> > > *vmf)
> > > }
> > > flush_cache_page(vma, vmf->address,
> > > pte_pfn(vmf->orig_pte));
> > > entry = mk_pte(new_page, vma->vm_page_prot);
> > > - entry = maybe_mkwrite(pte_mkdirty(entry), vma);
> > > + if (is_shstk_mapping(vma->vm_flags))
> > > + entry = pte_mkdirty_shstk(entry);
> > > + else
> > > + entry = pte_mkdirty(entry);
> > > + entry = maybe_mkwrite(entry, vma);
> > Do we want to lift this hunk of code and put it elsewhere? Maybe:
> >
> > entry = pte_set_vma_features(entry, vma);
> >
> > and then:
> >
> > pte_t pte_set_vma_features(pte_t entry, struct vm_area_struct)
> > {
> > /*
> > * Shadow stack PTEs are always dirty and always
> > * writable. They have a different encoding for
> > * this than normal PTEs, though.
> > */
> > if (is_shstk_mapping(vma->vm_flags))
> > entry = pte_mkdirty_shstk(entry);
> > else
> > entry = pte_mkdirty(entry);
> >
> > entry = maybe_mkwrite(entry, vma);
> >
> > return entry;
> > }
> Yes, that wants a helper like that. Not sold on the name, but
> whatever.
>
> Is there any way we can hide all the shadow stack magic in arch
> code?
We use is_shstk_mapping() only to determine PAGE_DIRTY_SW or
PAGE_DIRTY_HW should be set in a PTE. One way to remove this shadow
stack code from generic code is changing pte_mkdirty(pte) to
pte_mkdirty(pte, vma), and in the arch code we handle shadow stack.
Is this acceptable?
Thanks,
Yu-cheng
^ permalink raw reply
* Re: Kernel lockdown patch & IPAddressAllow/IPAddressDeny systemd feature with Secure Boot
From: Andrew Lutomirski @ 2018-08-14 14:14 UTC (permalink / raw)
To: dhowells, Linus Torvalds, ast, Laura Abbott, linux-kernel,
Linux API
Cc: Kernel Fedora
In-Reply-To: <CALeDE9ORLoyiUcf8Bmwr2rPyo7-3d8Fo54WuPGWtv4ByE_JG=Q@mail.gmail.com>
[Removed Fedora devel list because it's subscriber-only]
> On Aug 8, 2018, at 12:29 AM, Peter Robinson <pbrobinson@gmail.com> wrote:
>
> Probably a good idea to cc: this to the kernel list :-)
>
> I suspect it's intentional but with the planned changes for iptables
> etc to be backed by bpf in the upstream kernel sometime in the future
> it's likely going to need to be reviewed.
>
I thought this got covered in review. I think this part of lockdown
needs to get reverted or fixed ASAP.
(I definitely brought up multiple issues with the bpf lockdown stuff.
It's clearly extremely broken right now in the "new kernel breaks
*current* Linux distro" sense.)
> Peter
>
>> On Tue, Aug 7, 2018 at 10:25 PM, Timothée Ravier <tim@siosm.fr> wrote:
>> Booting Fedora with Secure Boot enabled will result in Lockdown being enabled at boot time. This will completly disable the BPF system call for all users [1][2].
>>
>> Unfortunately, this breaks the IPAddressAllow & IPAddressDeny systemd feature [3][4][5].
>>
>> I don't have a solution for this, but as far as I understand, this will also prevent other BPF use-cases (for example: Cilium on Fedora CoreOS).
>>
>> [1] https://src.fedoraproject.org/rpms/kernel/blob/master/f/efi-lockdown.patch#_1525
>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/jforbes/linux.git/commit/?h=lockdown&id=0eb0d0851747787f7182b3e9d0d38edb5925a678
>> [3] https://github.com/systemd/systemd/blob/master/src/core/bpf-firewall.c
>> [4] https://github.com/systemd/systemd/blob/master/NEWS#L1192
>> [5] https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#IPAddressAllow=ADDRESS%5B/PREFIXLENGTH%5D%E2%80%A6
>> _______________________________________________
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZMEWJMQH6DDMV3AZ4IG7LOYMMIETCH42/
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-leave@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RUWDEDQHS5I47YBPEZVEKXNU2BAX2SLU/
^ permalink raw reply
* Re: BUG: Mount ignores mount options
From: Casey Schaufler @ 2018-08-13 19:20 UTC (permalink / raw)
To: James Morris, Al Viro
Cc: Andy Lutomirski, Alan Cox, Theodore Y. Ts'o, David Howells,
Eric W. Biederman, John Johansen, Tejun Heo, SELinux-NSA,
Paul Moore, Li Zefan, Linux API, apparmor, Fenghua Yu,
Greg Kroah-Hartman, Eric Biggers, LSM List, Tetsuo Handa,
Johannes Weiner, Stephen Smalley, tomoyo-dev-en
In-Reply-To: <alpine.LRH.2.21.1808140458040.23296@namei.org>
On 8/13/2018 12:00 PM, James Morris wrote:
> On Mon, 13 Aug 2018, Al Viro wrote:
>
>> On Mon, Aug 13, 2018 at 09:48:53AM -0700, Andy Lutomirski wrote:
>>> 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.
^ permalink raw reply
* Re: BUG: Mount ignores mount options
From: James Morris @ 2018-08-13 19:00 UTC (permalink / raw)
To: Al Viro
Cc: Andy Lutomirski, Alan Cox, Theodore Y. Ts'o, David Howells,
Eric W. Biederman, John Johansen, Tejun Heo, SELinux-NSA,
Paul Moore, Li Zefan, Linux API, apparmor, Casey Schaufler,
Fenghua Yu, Greg Kroah-Hartman, Eric Biggers, LSM List,
Tetsuo Handa, Johannes Weiner, Stephen Smalley <sd>
In-Reply-To: <20180813172947.GS6515@ZenIV.linux.org.uk>
On Mon, 13 Aug 2018, Al Viro wrote:
> On Mon, Aug 13, 2018 at 09:48:53AM -0700, Andy Lutomirski wrote:
> > 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
<jmorris@namei.org>
^ permalink raw reply
* Re: BUG: Mount ignores mount options
From: Al Viro @ 2018-08-13 17:29 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Alan Cox, Theodore Y. Ts'o, David Howells, Eric W. Biederman,
John Johansen, Tejun Heo, SELinux-NSA, Paul Moore, Li Zefan,
Linux API, apparmor, Casey Schaufler, Fenghua Yu,
Greg Kroah-Hartman, Eric Biggers, LSM List, Tetsuo Handa,
Johannes Weiner, Stephen Smalley, tomoyo-dev-en
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.
^ permalink raw reply
* Re: BUG: Mount ignores mount options
From: Andy Lutomirski @ 2018-08-13 16:48 UTC (permalink / raw)
To: Alan Cox
Cc: Andy Lutomirski, Theodore Y. Ts'o, David Howells,
Eric W. Biederman, Al Viro, John Johansen, Tejun Heo, SELinux-NSA,
Paul Moore, Li Zefan, Linux API, apparmor, Casey Schaufler,
Fenghua Yu, Greg Kroah-Hartman, Eric Biggers, LSM List,
Tetsuo Handa, Johannes Weiner, Stephen Smalley
In-Reply-To: <20180813173502.1a7a1d9c@alans-desktop>
On Mon, Aug 13, 2018 at 9:35 AM, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:
>> 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.
^ permalink raw reply
* Re: BUG: Mount ignores mount options
From: Alan Cox @ 2018-08-13 16:35 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Theodore Y. Ts'o, David Howells, Eric W. Biederman, Al Viro,
John Johansen, Tejun Heo, SELinux-NSA, Paul Moore, Li Zefan,
Linux API, apparmor, Casey Schaufler, Fenghua Yu,
Greg Kroah-Hartman, Eric Biggers, LSM List, Tetsuo Handa,
Johannes Weiner, Stephen Smalley, tomoyo-dev-en
In-Reply-To: <CALCETrXC8Z-q+PzzqMC-McA7UdmFubVcs2dVsT0Dt+GbSqjF5A@mail.gmail.com>
> 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
^ permalink raw reply
* Re: BUG: Mount ignores mount options
From: Miklos Szeredi @ 2018-08-13 12:54 UTC (permalink / raw)
To: Al Viro
Cc: Eric W. Biederman, David Howells, John Johansen, Tejun Heo,
selinux, Paul Moore, Li Zefan, Linux API, apparmor,
Casey Schaufler, fenghua.yu, Greg Kroah-Hartman, Eric Biggers,
LSM, Tetsuo Handa, Johannes Weiner, Stephen Smalley,
tomoyo-dev-en, cgroups, Linus Torvalds, linux-fsdevel
In-Reply-To: <20180811015815.GD6515@ZenIV.linux.org.uk>
On Sat, Aug 11, 2018 at 3:58 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> What I'm saying is that the entire superblock-creating
> machinery - all of it - is nothing but library helpers. With the
> decision of when/how/if they are to be used being down to filesystem
> driver. Your "first mount"/"additional mount" simply do not map
> to anything universally applicable.
Why so? (Note: using the "mount" terminology here is fundamentally
broken to start with, mounts have nothing to do with this...
Filesystem instance is better word.)
You bring up NFS as an example, but creating and/or reusing an nfs
client instance connected to a certain server is certainly a clear and
well defined concept.
The question becomes: does it make sense to generalize this concept
and export it to userspace with the new API?
You know the Plan 9 fs interface much better, but to me it looks like
there's a separate namespace for filesystem instances, and the mount
command just refers to such an instance. So there's no comparing of
options or any such horror, just the need to explicitly instantiate a
new instance when necessary. Doesn't sound very difficult to
implement in the new API.
Thanks,
Miklos
^ permalink raw reply
* Re: [PATCH 28/33] vfs: syscall: Add fsconfig() for configuring and managing a context [ver #11]
From: Andy Lutomirski @ 2018-08-11 23:26 UTC (permalink / raw)
To: David Howells
Cc: Miklos Szeredi, Eric W. Biederman, Al Viro, Linux API,
Linus Torvalds, Linux FS Devel, LKML
In-Reply-To: <5152.1534018808@warthog.procyon.org.uk>
On Sat, Aug 11, 2018 at 1:20 PM, David Howells <dhowells@redhat.com> wrote:
> Miklos Szeredi <miklos@szeredi.hu> wrote:
>
>> You can determine at fsopen() time whether the filesystem is able to
>> support the O_EXCL behavior? If so, then it's trivial to enable this
>> conditionally. I think that's what Eric is asking for, it's obviously
>> not fair to ask for a change in behavior of the legacy interface.
>
> It's not trivial, see btrfs and nfs :-/
>
I'm not convinced that btrfs and nfs are the same situation. As far
as I can tell, in NFS's case, NFS shares superblocks as an
implementation detail. With Al's example, someone can do:
mount -t nfs4 wank.example.org:/foo/bar /mnt/a
mount -t nfs4 wank.example.org:/baz/barf /mnt/b
mount -t nfs4 wank.example.org:/foo/bar -o wsize=16384 /mnt/c
or equivalently create three fscontexts and FSCONFIG_CMD_CREATE all of
them, and the kernel creates one superblock for /mnt/a and /mnt/b and
a second one for /mnt/c. That seems like a good optimization, but I
think it really is just an optimization. In any sane implementation,
all three calls should succeed, and it should in general be possible
to create as many totally fresh mounts of the same network file system
as anyone wants.
Given this example, I think that it may be important to give
FSCONFIG_CMD_RECONFIGURE a very clear definition, and possibly a
definition that doesn't use the word superblock. After all, if
someone does FSCONFIG_CMD_RECONFIGURE on /mnt/a, if it really
reconfigures a *superblock*, then it will change /mnt/b as a side
effect but will not change /mnt/c. This seems like a mistake.
But I think that btrfs is quite a bit different. With btrfs, I can do:
mount -t btrfs /dev/sda1 -o subvol=a /mnt/a
mount -t btrfs /dev/sda1 -o subvol=b /mnt/b
and I get two mounts, each pointing at a different subvolume, that
(I'm pretty sure) share a superblock
mount -t btrfs /dev/sda1 -o subvol=c,foo=bar /mnt/c
where foo is a per-superblock option, it probably gets ignored. If I
set up /dev/mapper/foo as a linear alias for /dev/sda1 and I do:
mount -t btrfs /dev/mapper/foo -o subvol=d /mnt/d
then I get a fresh superblock. If /dev/sda1 is still mounted and the
various O_EXCL-like checks don'e catch it, then I get massive
corruption.
The btrfs case seems quite fragile to me, and it seems like a bit of
an abuse of mount(2). (Of course, basically everything anyone does
with mount(2) is a bit of an abuse.)
I would hope that the new fs mounting API would clean this up. The
NFS case seems just fine, but for btrfs, it seems like maybe the whole
CMD_CREATE operation should be more fine grained. There seem to be
*two* actions going on in a btrfs mount. First there's the act of
instantiating the filesystem driver backed by the device (I think this
is open_ctree()), and *then* there's the act of instantiating a dentry
tree pointing at some subvolume, etc.
ZFS seems to handle this quite nicely. First you fire up a zpool, and
then you start mounting its volumes.
^ permalink raw reply
* Re: [PATCH 28/33] vfs: syscall: Add fsconfig() for configuring and managing a context [ver #11]
From: David Howells @ 2018-08-11 20:20 UTC (permalink / raw)
To: Miklos Szeredi
Cc: dhowells, Eric W. Biederman, Al Viro, Linux API, Linus Torvalds,
linux-fsdevel, linux-kernel
In-Reply-To: <CAJfpegvWE9htLjqeR6=2BWBSuvJzJpWcjBC_EmX_k1RCGXTfbw@mail.gmail.com>
Miklos Szeredi <miklos@szeredi.hu> wrote:
> You can determine at fsopen() time whether the filesystem is able to
> support the O_EXCL behavior? If so, then it's trivial to enable this
> conditionally. I think that's what Eric is asking for, it's obviously
> not fair to ask for a change in behavior of the legacy interface.
It's not trivial, see btrfs and nfs :-/
David
^ permalink raw reply
* Re: BUG: Mount ignores mount options
From: Casey Schaufler @ 2018-08-11 17:47 UTC (permalink / raw)
To: Eric W. Biederman, Theodore Y. Ts'o
Cc: Eric Biggers, Tetsuo Handa, David Howells,
selinux-+05T5uksL2qpZYMLLGbcSA, Paul Moore, Miklos Szeredi,
Stephen Smalley, fenghua.yu-ral2JQCrhuEAvxtiuMwx3w,
apparmor-nLRlyDuq1AZFpShjVBNYrg,
tomoyo-dev-en-5NWGOfrQmneRv+LV9MX5uooqe+aC9MnS,
Greg Kroah-Hartman, Al Viro, cgroups-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Li Zefan,
Johannes Weiner, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, Tejun Heo,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
In-Reply-To: <8736vlo6ef.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
On 8/10/2018 9:48 PM, Eric W. Biederman wrote:
> "Theodore Y. Ts'o" <tytso@mit.edu> writes:
>
>> On Fri, Aug 10, 2018 at 08:05:44PM -0500, Eric W. Biederman wrote:
>>> My complaint is that the current implemented behavior of practically
>>> every filesystem in the kernel, is that it will ignore mount options
>>> when mounted a second time.
>> The file system is ***not*** mounted a second time.
>>
>> The design bug is that we allow bind mounts to be specified via a
>> block device. A bind mount is not "a second mount" of the file
>> system. Bind mounts != mounts.
>>
>> I had assumed we had allowed bind mounts to be specified via the block
>> device because of container use cases. If the container folks don't
>> want it, I would be pushing to simply not allow bind mounts to be
>> specified via block device at all.
> No it is not a container thing.
Inigo: "Hello. My name is Inigo Montoya. You killed my father. Prepare to die."
Rugen: "Stop saying that!"
Eric: "It is not a container thing."
Casey: "Stop saying that!"
Yes, Virginia, it *is* a container thing. Your container manager expects all
filesystems to be server-client based. It makes bad assumptions. It is doing
things that we would fire a sysadmin for doing. Don't blame the filesystems
for behaving as documented. Export the filesystem using NFS and mount them
using the NFS mechanism, which is designed to do what you're asking for. The
problem is not in the mount mechanism, it's in the way you want to abuse it.
>> The only reason why we should support it is because we don't want to
>> break scripts; and if the goal is not to break scripts, then we have
>> to keep to the current semantics, however broken you think it is.
> But we don't have to support returning filesystems with mismatched mount
> options in the new fsopen api. That is my concern. Confusing
> userspace this way has been shown to be harmful let's not keep doing it.
It's not "userspace" that's confused. Developers of userspace code
implementing system behavior (e.g. systemd, container managers) need to
understand how the system works. The container manager needs to know
that it can't mount filesystems with different options. That's the kind
of thing "managers" do. If it has to go to the mount table and check
on how the device is already mounted before doing a mount, so be it.
Unless, of course, you want the concept of "container" introduced into
the kernel. There's a whole lot of feldercarb that container managers
have to deal with that would be lots easier to deal with down below.
I'm not advocating that, and I understand the arguments against it.
On the other hand, if you want a platform that is optimized for a
container environment ...
> Eric
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
^ permalink raw reply
* Re: BUG: Mount ignores mount options
From: Al Viro @ 2018-08-11 16:51 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Eric Biggers, Tetsuo Handa, David Howells,
selinux-+05T5uksL2qpZYMLLGbcSA,
tomoyo-dev-en-5NWGOfrQmneRv+LV9MX5uooqe+aC9MnS, Paul Moore,
Miklos Szeredi, Stephen Smalley,
fenghua.yu-ral2JQCrhuEAvxtiuMwx3w,
apparmor-nLRlyDuq1AZFpShjVBNYrg, Greg Kroah-Hartman,
cgroups-u79uwXL29TY76Z2rM5mHXA, Theodore Y. Ts'o,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Li Zefan,
Eric W. Biederman, Johannes Weiner,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, Tejun Heo,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
In-Reply-To: <9B6E2781-484B-4C42-95F5-F900EA36CEA5-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
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
^ permalink raw reply
* Re: BUG: Mount ignores mount options
From: Andy Lutomirski @ 2018-08-11 16:31 UTC (permalink / raw)
To: David Howells
Cc: Eric W. Biederman, viro, John Johansen, Tejun Heo, selinux,
Paul Moore, Li Zefan, linux-api, apparmor, Casey Schaufler,
fenghua.yu, Greg Kroah-Hartman, Eric Biggers,
linux-security-module, Tetsuo Handa, Johannes Weiner,
Stephen Smalley, tomoyo-dev-en, cgroups, torvalds, linux-fsdevel,
linux-kernel, Theodore
In-Reply-To: <30365.1533972586@warthog.procyon.org.uk>
> On Aug 11, 2018, at 12:29 AM, David Howells <dhowells@redhat.com> wrote:
>
> Eric W. Biederman <ebiederm@xmission.com> wrote:
>
>>> 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).
^ permalink raw reply
* Re: BUG: Mount ignores mount options
From: David Howells @ 2018-08-11 7:29 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Eric Biggers, Tetsuo Handa, dhowells-H+wXaHxf7aLQT0dZR+AlfA,
selinux-+05T5uksL2qpZYMLLGbcSA,
tomoyo-dev-en-5NWGOfrQmneRv+LV9MX5uooqe+aC9MnS, Paul Moore,
Miklos Szeredi, Stephen Smalley,
fenghua.yu-ral2JQCrhuEAvxtiuMwx3w,
apparmor-nLRlyDuq1AZFpShjVBNYrg, Greg Kroah-Hartman,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
cgroups-u79uwXL29TY76Z2rM5mHXA, Theodore Y. Ts'o,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Li Zefan,
Johannes Weiner, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, Tejun Heo,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
In-Reply-To: <87pnyphf8i.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Eric W. Biederman <ebiederm@xmission.com> wrote:
> > 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
^ permalink raw reply
* Re: BUG: Mount ignores mount options
From: Eric W. Biederman @ 2018-08-11 4:48 UTC (permalink / raw)
To: Theodore Y. Ts'o
Cc: Al Viro, David Howells, John Johansen, Tejun Heo, selinux,
Paul Moore, Li Zefan, linux-api, apparmor, Casey Schaufler,
fenghua.yu, Greg Kroah-Hartman, Eric Biggers,
linux-security-module, Tetsuo Handa, Johannes Weiner,
Stephen Smalley, tomoyo-dev-en, cgroups, torvalds, linux-fsdevel,
linux-kernel, Miklos
In-Reply-To: <20180811014619.GA14368@thunk.org>
"Theodore Y. Ts'o" <tytso@mit.edu> writes:
> On Fri, Aug 10, 2018 at 08:05:44PM -0500, Eric W. Biederman wrote:
>>
>> My complaint is that the current implemented behavior of practically
>> every filesystem in the kernel, is that it will ignore mount options
>> when mounted a second time.
>
> The file system is ***not*** mounted a second time.
>
> The design bug is that we allow bind mounts to be specified via a
> block device. A bind mount is not "a second mount" of the file
> system. Bind mounts != mounts.
>
> I had assumed we had allowed bind mounts to be specified via the block
> device because of container use cases. If the container folks don't
> want it, I would be pushing to simply not allow bind mounts to be
> specified via block device at all.
No it is not a container thing.
> The only reason why we should support it is because we don't want to
> break scripts; and if the goal is not to break scripts, then we have
> to keep to the current semantics, however broken you think it is.
But we don't have to support returning filesystems with mismatched mount
options in the new fsopen api. That is my concern. Confusing
userspace this way has been shown to be harmful let's not keep doing it.
Eric
^ permalink raw reply
* Re: BUG: Mount ignores mount options
From: Eric W. Biederman @ 2018-08-11 4:43 UTC (permalink / raw)
To: Al Viro
Cc: David Howells, John Johansen, Tejun Heo, selinux, Paul Moore,
Li Zefan, linux-api, apparmor, Casey Schaufler, fenghua.yu,
Greg Kroah-Hartman, Eric Biggers, linux-security-module,
Tetsuo Handa, Johannes Weiner, Stephen Smalley, tomoyo-dev-en,
cgroups, torvalds, linux-fsdevel, linux-kernel,
Theodore Y. Ts'o, Miklos
In-Reply-To: <20180811021704.GE6515@ZenIV.linux.org.uk>
Al Viro <viro@ZenIV.linux.org.uk> writes:
> On Sat, Aug 11, 2018 at 02:58:15AM +0100, Al Viro wrote:
>> On Fri, Aug 10, 2018 at 08:05:44PM -0500, Eric W. Biederman wrote:
>>
>> > All I proposed was that we distinguish between a first mount and an
>> > additional mount so that userspace knows the options will be ignored.
>>
>> For pity sake, just what does it take to explain to you that your
>> notions of "first mount" and "additional mount" ARE HEAVILY FS-DEPENDENT
>> and may depend upon the pieces of state userland (especially in container)
>> simply does not have?
>>
>> One more time, slowly:
>>
>> mount -t nfs4 wank.example.org:/foo/bar /mnt/a
>> mount -t nfs4 wank.example.org:/baz/barf /mnt/b
>>
>> yield the same superblock. Is anyone who mounts something over NFS
>> required to know if anybody else has mounted something from the same
>> server, and if so how the hell are they supposed to find that out,
>> so that they could decide whether they are creating the "first" or
>> "additional" mount, whatever that might mean in this situation?
>>
>> And how, kernel-side, is that supposed to be handled by generic code
>> of any description?
>>
>> While we are at it,
>> mount -t nfs4 wank.example.org:/foo/bar -o wsize=16384 /mnt/c
>> is *NOT* the same superblock as the previous two.
>
> s/as the previous two/as in the previous two cases/, that is - the first two
> examples yield one superblock, this one - another.
Exactly because the mount options differ.
I don't have a problem if we have something sophisticated like nfs that
handles all of the hairy details and does not reuse a superblock unless the
mount options match.
What I have a problem with is the helper for ordinary filesystems that
are not as sophisticated as nfs that don't handle all of the option
magic and give userspace something different from what userspace asked
for.
It may take a little generalization of the definitions I proposed but it
still remains simple and straight forward.
CMD_THESE_MOUNT_OPTIONS_NO_SURPRISES
CMD_WHATEVER_ALREADY_EXISTS
Or we can make the filesystems more sophisticated when we move
them to the new API and perform the comparisons there. I think
that is what David Howells is working on.
Eric
^ permalink raw reply
* Re: [PATCH v4 0/4] seccomp trap to userspace
From: Tycho Andersen @ 2018-08-11 2:32 UTC (permalink / raw)
To: Dinesh Subhraveti
Cc: Kees Cook, Tobin Harding, linux-api, containers, Akihiro Suda,
Oleg Nesterov, linux-kernel, Eric W . Biederman,
Christian Brauner, Andy Lutomirski
In-Reply-To: <CAP4sa4+rODVahad2hW-L3h7k6fkfGBsoCfDfBVuMwp3Aaie2KA@mail.gmail.com>
On Tue, Aug 07, 2018 at 09:11:50PM -0700, Dinesh Subhraveti wrote:
> On Mon, Aug 6, 2018 at 7:44 PM, Tycho Andersen <tycho@tycho.ws> wrote:
> > Hi all,
> >
> > Dinesh Subhraveti has claimed that some part of this series might be
> > patented. While he has not furnished me with anything to confirm this
> > claim, I'll put this series on hold.
>
> For the sake of everyone's clarity, there is no patent or intellectual
> property issue here and we'd like to see this feature in the kernel. I did
> indicate that there is a patent related to the mechanism underlying this
> patch set but that is completely incidental to the issue here. We have
> filed that patent only for the purpose of defense and have no interest or
> resources to go after infringements. As such, I spoke about the approach,
> it's value for networking and a few possible ways of implementing it in the
> kernel at Linux Plumbers Conference 2017.
>
> As a contractor and a member of our team at AppSwitch (FKA Fermat), Tycho
> Andersen helped implement a fully user space version of system call trap
> mechanism based on seccomp / fd-passing and participated in our team
> discussions about upstreaming a kernel version of the feature. Given that
> context, we were taken aback that he posted the v1 patch set without
> letting us know and without any mention of AppSwitch in the post even
> though he was still under contract at that time.
It seems we disagree on the series of events, but agree that this
patchset should move forward. I'll work on preparing a v5.
Thanks!
Tycho
^ permalink raw reply
* Re: BUG: Mount ignores mount options
From: Al Viro @ 2018-08-11 2:17 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Howells, John Johansen, Tejun Heo, selinux, Paul Moore,
Li Zefan, linux-api, apparmor, Casey Schaufler, fenghua.yu,
Greg Kroah-Hartman, Eric Biggers, linux-security-module,
Tetsuo Handa, Johannes Weiner, Stephen Smalley, tomoyo-dev-en,
cgroups, torvalds, linux-fsdevel, linux-kernel,
Theodore Y. Ts'o, Miklos
In-Reply-To: <20180811015815.GD6515@ZenIV.linux.org.uk>
On Sat, Aug 11, 2018 at 02:58:15AM +0100, Al Viro wrote:
> On Fri, Aug 10, 2018 at 08:05:44PM -0500, Eric W. Biederman wrote:
>
> > All I proposed was that we distinguish between a first mount and an
> > additional mount so that userspace knows the options will be ignored.
>
> For pity sake, just what does it take to explain to you that your
> notions of "first mount" and "additional mount" ARE HEAVILY FS-DEPENDENT
> and may depend upon the pieces of state userland (especially in container)
> simply does not have?
>
> One more time, slowly:
>
> mount -t nfs4 wank.example.org:/foo/bar /mnt/a
> mount -t nfs4 wank.example.org:/baz/barf /mnt/b
>
> yield the same superblock. Is anyone who mounts something over NFS
> required to know if anybody else has mounted something from the same
> server, and if so how the hell are they supposed to find that out,
> so that they could decide whether they are creating the "first" or
> "additional" mount, whatever that might mean in this situation?
>
> And how, kernel-side, is that supposed to be handled by generic code
> of any description?
>
> While we are at it,
> mount -t nfs4 wank.example.org:/foo/bar -o wsize=16384 /mnt/c
> is *NOT* the same superblock as the previous two.
s/as the previous two/as in the previous two cases/, that is - the first two
examples yield one superblock, this one - another.
^ permalink raw reply
* Re: BUG: Mount ignores mount options
From: Al Viro @ 2018-08-11 1:58 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Howells, John Johansen, Tejun Heo, selinux, Paul Moore,
Li Zefan, linux-api, apparmor, Casey Schaufler, fenghua.yu,
Greg Kroah-Hartman, Eric Biggers, linux-security-module,
Tetsuo Handa, Johannes Weiner, Stephen Smalley, tomoyo-dev-en,
cgroups, torvalds, linux-fsdevel, linux-kernel,
Theodore Y. Ts'o, Miklos
In-Reply-To: <87pnypiufr.fsf@xmission.com>
On Fri, Aug 10, 2018 at 08:05:44PM -0500, Eric W. Biederman wrote:
> All I proposed was that we distinguish between a first mount and an
> additional mount so that userspace knows the options will be ignored.
For pity sake, just what does it take to explain to you that your
notions of "first mount" and "additional mount" ARE HEAVILY FS-DEPENDENT
and may depend upon the pieces of state userland (especially in container)
simply does not have?
One more time, slowly:
mount -t nfs4 wank.example.org:/foo/bar /mnt/a
mount -t nfs4 wank.example.org:/baz/barf /mnt/b
yield the same superblock. Is anyone who mounts something over NFS
required to know if anybody else has mounted something from the same
server, and if so how the hell are they supposed to find that out,
so that they could decide whether they are creating the "first" or
"additional" mount, whatever that might mean in this situation?
And how, kernel-side, is that supposed to be handled by generic code
of any description?
While we are at it,
mount -t nfs4 wank.example.org:/foo/bar -o wsize=16384 /mnt/c
is *NOT* the same superblock as the previous two.
> I don't know how the above wound up being construed as asking that the
> code call sget directly but that is what has happened.
Not by me. What I'm saying is that the entire superblock-creating
machinery - all of it - is nothing but library helpers. With the
decision of when/how/if they are to be used being down to filesystem
driver. Your "first mount"/"additional mount" simply do not map
to anything universally applicable.
> > 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.
>
> Normal forms etc. If we want to do that it just requires a wee bit of
> discipline. And if all of the option parsing is being rewritten and
> retested anyway I don't see why we can't do something like that as well.
> So it does not sound unreasonable to me.
See above.
^ permalink raw reply
* Re: BUG: Mount ignores mount options
From: Theodore Y. Ts'o @ 2018-08-11 1:46 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Eric Biggers, Tetsuo Handa, David Howells,
selinux-+05T5uksL2qpZYMLLGbcSA,
tomoyo-dev-en-5NWGOfrQmneRv+LV9MX5uooqe+aC9MnS, Paul Moore,
Miklos Szeredi, Stephen Smalley,
fenghua.yu-ral2JQCrhuEAvxtiuMwx3w,
apparmor-nLRlyDuq1AZFpShjVBNYrg, Greg Kroah-Hartman, Al Viro,
cgroups-u79uwXL29TY76Z2rM5mHXA, linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA, Li Zefan,
Johannes Weiner, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, Tejun Heo,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
In-Reply-To: <87pnypiufr.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
On Fri, Aug 10, 2018 at 08:05:44PM -0500, Eric W. Biederman wrote:
>
> My complaint is that the current implemented behavior of practically
> every filesystem in the kernel, is that it will ignore mount options
> when mounted a second time.
The file system is ***not*** mounted a second time.
The design bug is that we allow bind mounts to be specified via a
block device. A bind mount is not "a second mount" of the file
system. Bind mounts != mounts.
I had assumed we had allowed bind mounts to be specified via the block
device because of container use cases. If the container folks don't
want it, I would be pushing to simply not allow bind mounts to be
specified via block device at all.
The only reason why we should support it is because we don't want to
break scripts; and if the goal is not to break scripts, then we have
to keep to the current semantics, however broken you think it is.
- Ted
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
^ permalink raw reply
* Re: BUG: Mount ignores mount options
From: Eric W. Biederman @ 2018-08-11 1:32 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Eric Biggers, Tetsuo Handa, LKML, David Howells, SELinux-NSA,
tomoyo-dev-en-5NWGOfrQmneRv+LV9MX5uooqe+aC9MnS, Paul Moore,
Miklos Szeredi, Stephen Smalley, Fenghua Yu,
apparmor-nLRlyDuq1AZFpShjVBNYrg, Tejun Heo, Al Viro,
Andy Lutomirski, open list:CONTROL GROUP (CGROUP),
Theodore Y. Ts'o, Linux API, Greg Kroah-Hartman, LSM List,
Li Zefan, Johannes Weiner, Linux FS Devel, Linus Torvalds
In-Reply-To: <20180811003852.GA10463@magnolia>
"Darrick J. Wong" <darrick.wong@oracle.com> writes:
> On Fri, Aug 10, 2018 at 07:54:47PM -0400, Theodore Y. Ts'o wrote:
>> 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.
For me I am happy with fuse. That is sufficient to cover any container
use cases people have. If anyone comes bugging you for more I will be
happy to push back.
The only thing that containers have to do with this is I wind up
touching a lot of the kernel/user boundary so I get to see a lot of it
and sometimes see weird things.
Eric
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox