On Fri, Aug 10, 2018 at 7:01 PM Jann Horn wrote:
> On Thu, Aug 9, 2018 at 4:07 AM Paul Moore wrote:
> > On Wed, Aug 8, 2018 at 9:56 PM Paul Moore wrote:
> > > On Mon, Aug 6, 2018 at 5:19 PM Jann Horn wrote:
> > > >
> > > > The intended behavior change for this patch is to reject any MLS
On Mon, Aug 13, 2018 at 1:49 PM Hollis Blanchard
wrote:
>
> On 08/13/2018 01:45 PM, Tom Cherry wrote:
> > On Mon, Aug 13, 2018 at 12:43 PM Hollis Blanchard
> > wrote:
> >> The __atomic_* GCC primitives were introduced in GCC 4.7, but Red Hat
> >> Enterprise Linux 6.x (for example) provides GCC
On Mon, Aug 13, 2018 at 12:43 PM Hollis Blanchard
wrote:
>
> The __atomic_* GCC primitives were introduced in GCC 4.7, but Red Hat
> Enterprise Linux 6.x (for example) provides GCC 4.4. Tweak the current code to
> use the (most conservative) __sync_synchronize() primitive provided by those
>
The __atomic_* GCC primitives were introduced in GCC 4.7, but Red Hat
Enterprise Linux 6.x (for example) provides GCC 4.4. Tweak the current code to
use the (most conservative) __sync_synchronize() primitive provided by those
older GCC versions.
Fixes
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
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
> 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 08/13/2018 08:59 AM, Sachin Grover wrote:
I agree with you that it cannot be exploitable on Android, but Kasan is
able to find it as OOB if I run syzkaller on x86 based VM image. My last
commit is actually only fixing one path, but there are multiple path
which are having same issue, so it
I agree with you that it cannot be exploitable on Android, but Kasan is able to
find it as OOB if I run syzkaller on x86 based VM image. My last commit is
actually only fixing one path, but there are multiple path which are having
same issue, so it would be better if fix is given in
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"
On 08/13/2018 08:23 AM, Stephen Smalley wrote:
On 08/13/2018 01:19 AM, Sachin Grover wrote:
Hi Stephen/Paul,
This issue was discovered using
https://android.googlesource.com/kernel/common -b android-4.9-o, but
I've verified the code path exists in msm-4.4. It likely exists in
other kernel
On 08/13/2018 01:19 AM, Sachin Grover wrote:
Hi Stephen/Paul,
This issue was discovered using
https://android.googlesource.com/kernel/common -b android-4.9-o, but
I've verified the code path exists in msm-4.4. It likely exists in other
kernel versions as well.
As a privileged user, one can
Hi Stephen/Paul,
This issue was discovered using https://android.googlesource.com/kernel/common
-b android-4.9-o, but I've verified the code path exists in msm-4.4. It likely
exists in other kernel versions as well.
As a privileged user, one can override the current SELinux context via a call
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
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
> 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
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,
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
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
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
"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.
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
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.
"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
On Thu, Aug 9, 2018 at 4:07 AM Paul Moore wrote:
>
> On Wed, Aug 8, 2018 at 9:56 PM Paul Moore wrote:
> >
> > On Mon, Aug 6, 2018 at 5:19 PM Jann Horn wrote:
> > >
> > > The intended behavior change for this patch is to reject any MLS strings
> > > that contain (trailing) garbage if
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
32 matches
Mail list logo
