> 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.
>
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
> i
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
ex
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 belo
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 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 fo
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 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 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 n
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,
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.
Da
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:
>
> U
"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; sh
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, someone
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.
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 07:54:47PM -0400, Theodore Y. Ts'o wrote:
> 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 filesyst
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 f
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:
> > 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 f
"Theodore Y. Ts'o" writes:
> 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
Al Viro writes:
> 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 fol
David Howells writes:
> 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. S
"Darrick J. Wong" 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,
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
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
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 moun
"Theodore Y. Ts'o" 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
Al Viro 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.
28 matches
Mail list logo