Quoting James Morris (jmor...@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
Casey Schaufler 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 i
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.
>>
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 th
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
On Mon, Aug 13, 2018 at 9:35 AM, Alan Cox 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 strea
> 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
On Sat, Aug 11, 2018 at 3:58 AM, Al Viro 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" sim
On 8/10/2018 9:48 PM, Eric W. Biederman wrote:
> "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
>>>
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,
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.
"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
Eric W. Biederman 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 interfac
> On Aug 11, 2018, at 12:29 AM, David Howells wrote:
>
> Eric W. Biederman 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 endo
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 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
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
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
"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
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
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
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
"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 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
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, someone
"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
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 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
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 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 belo
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.
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
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
> i
> 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
ex
40 matches
Mail list logo
