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
On Fri, Aug 10, 2018 at 9:14 AM, Theodore Y. Ts'o 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,
"Theodore Y. Ts'o" writes:
> 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;
On Fri, Aug 10, 2018 at 04:53:58PM +0100, David Howells wrote:
> Theodore Y. Ts'o 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:
>
>
Casey Schaufler wrote:
> > 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.
Yes. I'm doing that.
On 8/10/2018 8:39 AM, Theodore Y. Ts'o wrote:
> 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
Theodore Y. Ts'o 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,
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
>
On Fri, Aug 10, 2018 at 07:36:17AM -0700, Andy Lutomirski wrote:
>
>
> > On Aug 10, 2018, at 7:05 AM, 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
On 2018/08/10 23:05, 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
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
>
Andy Lutomirski writes:
>> On Aug 10, 2018, at 7:05 AM, 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
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.
Yes. Since you *absolutely* *insist* on
Andy Lutomirski wrote:
> > /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
>
> To make sure I understand correctly: the problem is that the second mount
>
> On Aug 10, 2018, at 7:05 AM, 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.
>
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
16 matches
Mail list logo
