On Mon, Mar 4, 2019 at 8:53 PM Stephen Smalley wrote:
>
> On 3/4/19 12:01 PM, Mark Salyzyn wrote:
> > On 11/29/2018 05:49 AM, Vivek Goyal wrote:
> >> So will override_creds=off solve the NFS issue also where all access will
> >> happen with the creds of task now? Though it will stil require more
On 3/4/19 12:01 PM, Mark Salyzyn wrote:
On 11/29/2018 05:49 AM, Vivek Goyal wrote:
So will override_creds=off solve the NFS issue also where all access will
happen with the creds of task now? Though it will stil require more
priviliges in task for other operations in overlay to succeed.
NFS
On 3/4/2019 9:01 AM, Mark Salyzyn wrote:
Adding linux-security-module to the CC. Please keep the general
LSM community in to loop.
On 11/29/2018 05:49 AM, Vivek Goyal wrote:
So will override_creds=off solve the NFS issue also where all access
will
happen with the creds of task now? Though
On 11/29/2018 05:49 AM, Vivek Goyal wrote:
So will override_creds=off solve the NFS issue also where all access will
happen with the creds of task now? Though it will stil require more
priviliges in task for other operations in overlay to succeed.
NFS problems seems to have ended the
On Thu, Dec 13, 2018 at 03:09:55PM -0500, Stephen Smalley wrote:
> On 12/13/18 1:54 PM, Vivek Goyal wrote:
> > On Thu, Dec 13, 2018 at 11:12:31AM -0500, Stephen Smalley wrote:
> >
> > [..]
> > > > > > Can you elaborate a bit more on how this is leaking data through
> > > > > > overlay
> > > > >
On 12/13/18 1:54 PM, Vivek Goyal wrote:
On Thu, Dec 13, 2018 at 11:12:31AM -0500, Stephen Smalley wrote:
[..]
Can you elaborate a bit more on how this is leaking data through overlay
mount. If it is, then why accessing file on lower is not equivalent of
leaking of data.
In the container use
On Thu, Dec 13, 2018 at 11:12:31AM -0500, Stephen Smalley wrote:
[..]
> > > > Can you elaborate a bit more on how this is leaking data through overlay
> > > > mount. If it is, then why accessing file on lower is not equivalent of
> > > > leaking of data.
> > >
> > > In the container use case,
On 12/13/18 9:58 AM, Vivek Goyal wrote:
On Wed, Dec 12, 2018 at 09:51:59AM -0500, Stephen Smalley wrote:
On 12/11/18 4:48 PM, Vivek Goyal wrote:
On Thu, Dec 06, 2018 at 03:26:26PM -0500, Stephen Smalley wrote:
On 12/5/18 8:43 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 11:49:16AM -0500,
On Wed, Dec 12, 2018 at 09:51:59AM -0500, Stephen Smalley wrote:
> On 12/11/18 4:48 PM, Vivek Goyal wrote:
> > On Thu, Dec 06, 2018 at 03:26:26PM -0500, Stephen Smalley wrote:
> > > On 12/5/18 8:43 AM, Vivek Goyal wrote:
> > > > On Tue, Dec 04, 2018 at 11:49:16AM -0500, Stephen Smalley wrote:
> >
On 12/11/18 4:48 PM, Vivek Goyal wrote:
On Thu, Dec 06, 2018 at 03:26:26PM -0500, Stephen Smalley wrote:
On 12/5/18 8:43 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 11:49:16AM -0500, Stephen Smalley wrote:
On 12/4/18 11:17 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 11:05:46AM -0500,
On Thu, Dec 06, 2018 at 03:26:26PM -0500, Stephen Smalley wrote:
> On 12/5/18 8:43 AM, Vivek Goyal wrote:
> > On Tue, Dec 04, 2018 at 11:49:16AM -0500, Stephen Smalley wrote:
> > > On 12/4/18 11:17 AM, Vivek Goyal wrote:
> > > > On Tue, Dec 04, 2018 at 11:05:46AM -0500, Stephen Smalley wrote:
> >
On Tue, Dec 4, 2018 at 10:39 AM Miklos Szeredi wrote:
> On Tue, Dec 4, 2018 at 4:32 PM Stephen Smalley wrote:
>
> > Ok, I concede the point. Not sure what that means though for v4.20.
>
> I have the revert queued up for v4.20 as that's the safest.
Miklos, when do you plan on sending the revert
On 12/5/18 8:43 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 11:49:16AM -0500, Stephen Smalley wrote:
On 12/4/18 11:17 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 11:05:46AM -0500, Stephen Smalley wrote:
On 12/4/18 10:42 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 04:31:09PM +0100,
On 12/5/18 8:43 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 11:49:16AM -0500, Stephen Smalley wrote:
On 12/4/18 11:17 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 11:05:46AM -0500, Stephen Smalley wrote:
On 12/4/18 10:42 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 04:31:09PM +0100,
On Tue, Dec 04, 2018 at 11:49:16AM -0500, Stephen Smalley wrote:
> On 12/4/18 11:17 AM, Vivek Goyal wrote:
> > On Tue, Dec 04, 2018 at 11:05:46AM -0500, Stephen Smalley wrote:
> > > On 12/4/18 10:42 AM, Vivek Goyal wrote:
> > > > On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote:
> >
On Tue, Dec 04, 2018 at 11:49:16AM -0500, Stephen Smalley wrote:
> On 12/4/18 11:17 AM, Vivek Goyal wrote:
> > On Tue, Dec 04, 2018 at 11:05:46AM -0500, Stephen Smalley wrote:
> > > On 12/4/18 10:42 AM, Vivek Goyal wrote:
> > > > On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote:
> >
On Tue, Dec 4, 2018 at 9:40 AM Stephen Smalley wrote:
> On 12/3/18 6:27 PM, Paul Moore wrote:
> > On Thu, Nov 29, 2018 at 5:22 PM Daniel Walsh wrote:
> >> On 11/29/18 2:47 PM, Miklos Szeredi wrote:
> >>> On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley
> >>> wrote:
> >>>
> Possibly I
On Tue, Dec 4, 2018 at 9:40 AM Stephen Smalley wrote:
> On 12/3/18 6:27 PM, Paul Moore wrote:
> > On Thu, Nov 29, 2018 at 5:22 PM Daniel Walsh wrote:
> >> On 11/29/18 2:47 PM, Miklos Szeredi wrote:
> >>> On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley
> >>> wrote:
> >>>
> Possibly I
On 12/4/18 11:17 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 11:05:46AM -0500, Stephen Smalley wrote:
On 12/4/18 10:42 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote:
On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote:
Having said that, this still
On 12/4/18 11:17 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 11:05:46AM -0500, Stephen Smalley wrote:
On 12/4/18 10:42 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote:
On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote:
Having said that, this still
On Tue, Dec 04, 2018 at 11:05:46AM -0500, Stephen Smalley wrote:
> On 12/4/18 10:42 AM, Vivek Goyal wrote:
> > On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote:
> > > On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote:
> > >
> > > > Having said that, this still create little anomaly
On Tue, Dec 04, 2018 at 11:05:46AM -0500, Stephen Smalley wrote:
> On 12/4/18 10:42 AM, Vivek Goyal wrote:
> > On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote:
> > > On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote:
> > >
> > > > Having said that, this still create little anomaly
On Tue, Dec 04, 2018 at 10:42:35AM -0500, Stephen Smalley wrote:
[..]
> > > Yes, in that case there isn't an escalation of privilege for the mounter
> > > (I
> > > acknowledged that above). I'm still not sure copy-up of special files is
> > > a
> > > good idea though:
> > >
> > > - In the
On Tue, Dec 04, 2018 at 10:42:35AM -0500, Stephen Smalley wrote:
[..]
> > > Yes, in that case there isn't an escalation of privilege for the mounter
> > > (I
> > > acknowledged that above). I'm still not sure copy-up of special files is
> > > a
> > > good idea though:
> > >
> > > - In the
On 12/4/18 10:42 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote:
On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote:
Having said that, this still create little anomaly when mknod to client
is not allowed on context label. So a device file, which is on
On 12/4/18 10:42 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote:
On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote:
Having said that, this still create little anomaly when mknod to client
is not allowed on context label. So a device file, which is on
On 12/4/18 9:45 AM, Miklos Szeredi wrote:
On Tue, Dec 4, 2018 at 3:28 PM Stephen Smalley wrote:
On 12/4/18 8:32 AM, Miklos Szeredi wrote:
My proposed sequence would be
a) check task's creds against overlay inode, fail -> return fail, otherwise:
b) check mounter's creds against lower
On 12/4/18 9:45 AM, Miklos Szeredi wrote:
On Tue, Dec 4, 2018 at 3:28 PM Stephen Smalley wrote:
On 12/4/18 8:32 AM, Miklos Szeredi wrote:
My proposed sequence would be
a) check task's creds against overlay inode, fail -> return fail, otherwise:
b) check mounter's creds against lower
On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote:
> On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote:
>
> > Having said that, this still create little anomaly when mknod to client
> > is not allowed on context label. So a device file, which is on lower
> > and client can not open
On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote:
> On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote:
>
> > Having said that, this still create little anomaly when mknod to client
> > is not allowed on context label. So a device file, which is on lower
> > and client can not open
On 12/4/18 10:15 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 09:30:53AM -0500, Stephen Smalley wrote:
On 12/4/18 8:32 AM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 10:16 PM Stephen Smalley wrote:
On 11/29/18 4:03 PM, Stephen Smalley wrote:
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
On 12/4/18 10:15 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 09:30:53AM -0500, Stephen Smalley wrote:
On 12/4/18 8:32 AM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 10:16 PM Stephen Smalley wrote:
On 11/29/18 4:03 PM, Stephen Smalley wrote:
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
On Tue, Dec 4, 2018 at 4:32 PM Stephen Smalley wrote:
> Ok, I concede the point. Not sure what that means though for v4.20.
I have the revert queued up for v4.20 as that's the safest.
Don't let that stop the discussion, though, I'd especially like to
hear the arguments from the Android side.
On Tue, Dec 4, 2018 at 4:32 PM Stephen Smalley wrote:
> Ok, I concede the point. Not sure what that means though for v4.20.
I have the revert queued up for v4.20 as that's the safest.
Don't let that stop the discussion, though, I'd especially like to
hear the arguments from the Android side.
On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote:
> Having said that, this still create little anomaly when mknod to client
> is not allowed on context label. So a device file, which is on lower
> and client can not open it for read/write on host, it can now be opened
> for read/write because
On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote:
> Having said that, this still create little anomaly when mknod to client
> is not allowed on context label. So a device file, which is on lower
> and client can not open it for read/write on host, it can now be opened
> for read/write because
On Tue, Dec 04, 2018 at 10:15:49AM -0500, Vivek Goyal wrote:
> On Tue, Dec 04, 2018 at 09:30:53AM -0500, Stephen Smalley wrote:
> > On 12/4/18 8:32 AM, Miklos Szeredi wrote:
> > > On Thu, Nov 29, 2018 at 10:16 PM Stephen Smalley
> > > wrote:
> > > >
> > > > On 11/29/18 4:03 PM, Stephen Smalley
On Tue, Dec 04, 2018 at 10:15:49AM -0500, Vivek Goyal wrote:
> On Tue, Dec 04, 2018 at 09:30:53AM -0500, Stephen Smalley wrote:
> > On 12/4/18 8:32 AM, Miklos Szeredi wrote:
> > > On Thu, Nov 29, 2018 at 10:16 PM Stephen Smalley
> > > wrote:
> > > >
> > > > On 11/29/18 4:03 PM, Stephen Smalley
On Tue, Dec 04, 2018 at 09:30:53AM -0500, Stephen Smalley wrote:
> On 12/4/18 8:32 AM, Miklos Szeredi wrote:
> > On Thu, Nov 29, 2018 at 10:16 PM Stephen Smalley wrote:
> > >
> > > On 11/29/18 4:03 PM, Stephen Smalley wrote:
> > > > On 11/29/18 2:47 PM, Miklos Szeredi wrote:
> > > > > On Thu,
On Tue, Dec 04, 2018 at 09:30:53AM -0500, Stephen Smalley wrote:
> On 12/4/18 8:32 AM, Miklos Szeredi wrote:
> > On Thu, Nov 29, 2018 at 10:16 PM Stephen Smalley wrote:
> > >
> > > On 11/29/18 4:03 PM, Stephen Smalley wrote:
> > > > On 11/29/18 2:47 PM, Miklos Szeredi wrote:
> > > > > On Thu,
On Tue, Dec 4, 2018 at 3:28 PM Stephen Smalley wrote:
>
> On 12/4/18 8:32 AM, Miklos Szeredi wrote:
> > My proposed sequence would be
> >
> > a) check task's creds against overlay inode, fail -> return fail, otherwise:
> > b) check mounter's creds against lower inode, success -> return
> >
On Tue, Dec 4, 2018 at 3:28 PM Stephen Smalley wrote:
>
> On 12/4/18 8:32 AM, Miklos Szeredi wrote:
> > My proposed sequence would be
> >
> > a) check task's creds against overlay inode, fail -> return fail, otherwise:
> > b) check mounter's creds against lower inode, success -> return
> >
On 12/3/18 6:27 PM, Paul Moore wrote:
On Thu, Nov 29, 2018 at 5:22 PM Daniel Walsh wrote:
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote:
Possibly I misunderstood you, but I don't think we want to copy-up on
permission denial, as that would
On 12/3/18 6:27 PM, Paul Moore wrote:
On Thu, Nov 29, 2018 at 5:22 PM Daniel Walsh wrote:
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote:
Possibly I misunderstood you, but I don't think we want to copy-up on
permission denial, as that would
On 12/4/18 8:32 AM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 10:16 PM Stephen Smalley wrote:
On 11/29/18 4:03 PM, Stephen Smalley wrote:
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley
wrote:
Possibly I misunderstood you, but I don't think
On 12/4/18 8:32 AM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 10:16 PM Stephen Smalley wrote:
On 11/29/18 4:03 PM, Stephen Smalley wrote:
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley
wrote:
Possibly I misunderstood you, but I don't think
On Thu, Nov 29, 2018 at 10:16 PM Stephen Smalley wrote:
>
> On 11/29/18 4:03 PM, Stephen Smalley wrote:
> > On 11/29/18 2:47 PM, Miklos Szeredi wrote:
> >> On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley
> >> wrote:
> >>
> >>> Possibly I misunderstood you, but I don't think we want to copy-up on
On Thu, Nov 29, 2018 at 10:16 PM Stephen Smalley wrote:
>
> On 11/29/18 4:03 PM, Stephen Smalley wrote:
> > On 11/29/18 2:47 PM, Miklos Szeredi wrote:
> >> On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley
> >> wrote:
> >>
> >>> Possibly I misunderstood you, but I don't think we want to copy-up on
On Thu, Nov 29, 2018 at 5:22 PM Daniel Walsh wrote:
> On 11/29/18 2:47 PM, Miklos Szeredi wrote:
> > On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote:
> >
> >> Possibly I misunderstood you, but I don't think we want to copy-up on
> >> permission denial, as that would still allow the mounter
On Thu, Nov 29, 2018 at 5:22 PM Daniel Walsh wrote:
> On 11/29/18 2:47 PM, Miklos Szeredi wrote:
> > On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote:
> >
> >> Possibly I misunderstood you, but I don't think we want to copy-up on
> >> permission denial, as that would still allow the mounter
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
> On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote:
>
>> Possibly I misunderstood you, but I don't think we want to copy-up on
>> permission denial, as that would still allow the mounter to read/write
>> special files or execute regular files to
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
> On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote:
>
>> Possibly I misunderstood you, but I don't think we want to copy-up on
>> permission denial, as that would still allow the mounter to read/write
>> special files or execute regular files to
On 11/29/18 4:03 PM, Stephen Smalley wrote:
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley
wrote:
Possibly I misunderstood you, but I don't think we want to copy-up on
permission denial, as that would still allow the mounter to read/write
special
On 11/29/18 4:03 PM, Stephen Smalley wrote:
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley
wrote:
Possibly I misunderstood you, but I don't think we want to copy-up on
permission denial, as that would still allow the mounter to read/write
special
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote:
Possibly I misunderstood you, but I don't think we want to copy-up on
permission denial, as that would still allow the mounter to read/write
special files or execute regular files to which it
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote:
Possibly I misunderstood you, but I don't think we want to copy-up on
permission denial, as that would still allow the mounter to read/write
special files or execute regular files to which it
On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote:
> Possibly I misunderstood you, but I don't think we want to copy-up on
> permission denial, as that would still allow the mounter to read/write
> special files or execute regular files to which it would normally be
> denied access, because
On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote:
> Possibly I misunderstood you, but I don't think we want to copy-up on
> permission denial, as that would still allow the mounter to read/write
> special files or execute regular files to which it would normally be
> denied access, because
On 11/29/18 6:04 AM, Miklos Szeredi wrote:
On Wed, Nov 28, 2018 at 10:43 PM Stephen Smalley wrote:
On 11/28/18 3:24 PM, Miklos Szeredi wrote:
On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley wrote:
[...]
Does the breaking commit (007ea44892e6) fix a real bug affecting users?
If not,
On 11/29/18 6:04 AM, Miklos Szeredi wrote:
On Wed, Nov 28, 2018 at 10:43 PM Stephen Smalley wrote:
On 11/28/18 3:24 PM, Miklos Szeredi wrote:
On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley wrote:
[...]
Does the breaking commit (007ea44892e6) fix a real bug affecting users?
If not,
On 11/29/18 11:16 AM, Stephen Smalley wrote:
On 11/29/18 6:04 AM, Miklos Szeredi wrote:
On Wed, Nov 28, 2018 at 10:43 PM Stephen Smalley
wrote:
On 11/28/18 3:24 PM, Miklos Szeredi wrote:
On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley
wrote:
[...]
Does the breaking commit (007ea44892e6)
On 11/29/18 11:16 AM, Stephen Smalley wrote:
On 11/29/18 6:04 AM, Miklos Szeredi wrote:
On Wed, Nov 28, 2018 at 10:43 PM Stephen Smalley
wrote:
On 11/28/18 3:24 PM, Miklos Szeredi wrote:
On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley
wrote:
[...]
Does the breaking commit (007ea44892e6)
On Thu, Nov 29, 2018 at 12:04:20PM +0100, Miklos Szeredi wrote:
> On Wed, Nov 28, 2018 at 10:43 PM Stephen Smalley wrote:
> >
> > On 11/28/18 3:24 PM, Miklos Szeredi wrote:
> > > On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley
> > > wrote:
>
> [...]
>
> > >> Does the breaking commit
On Thu, Nov 29, 2018 at 12:04:20PM +0100, Miklos Szeredi wrote:
> On Wed, Nov 28, 2018 at 10:43 PM Stephen Smalley wrote:
> >
> > On 11/28/18 3:24 PM, Miklos Szeredi wrote:
> > > On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley
> > > wrote:
>
> [...]
>
> > >> Does the breaking commit
On Wed, Nov 28, 2018 at 10:43 PM Stephen Smalley wrote:
>
> On 11/28/18 3:24 PM, Miklos Szeredi wrote:
> > On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley wrote:
[...]
> >> Does the breaking commit (007ea44892e6) fix a real bug affecting users?
> >>If not, I'd recommend just reverting it.
On Wed, Nov 28, 2018 at 10:43 PM Stephen Smalley wrote:
>
> On 11/28/18 3:24 PM, Miklos Szeredi wrote:
> > On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley wrote:
[...]
> >> Does the breaking commit (007ea44892e6) fix a real bug affecting users?
> >>If not, I'd recommend just reverting it.
On 11/28/18 3:24 PM, Miklos Szeredi wrote:
On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley wrote:
On 11/28/18 12:03 PM, Vivek Goyal wrote:
On Wed, Nov 28, 2018 at 11:00:09AM +0100, Miklos Szeredi wrote:
On Tue, Nov 27, 2018 at 10:05 PM Vivek Goyal wrote:
On Tue, Nov 27, 2018 at
On 11/28/18 3:24 PM, Miklos Szeredi wrote:
On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley wrote:
On 11/28/18 12:03 PM, Vivek Goyal wrote:
On Wed, Nov 28, 2018 at 11:00:09AM +0100, Miklos Szeredi wrote:
On Tue, Nov 27, 2018 at 10:05 PM Vivek Goyal wrote:
On Tue, Nov 27, 2018 at
On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley wrote:
>
> On 11/28/18 12:03 PM, Vivek Goyal wrote:
> > On Wed, Nov 28, 2018 at 11:00:09AM +0100, Miklos Szeredi wrote:
> >> On Tue, Nov 27, 2018 at 10:05 PM Vivek Goyal wrote:
> >>>
> >>> On Tue, Nov 27, 2018 at 08:58:06PM +0100, Miklos Szeredi
On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley wrote:
>
> On 11/28/18 12:03 PM, Vivek Goyal wrote:
> > On Wed, Nov 28, 2018 at 11:00:09AM +0100, Miklos Szeredi wrote:
> >> On Tue, Nov 27, 2018 at 10:05 PM Vivek Goyal wrote:
> >>>
> >>> On Tue, Nov 27, 2018 at 08:58:06PM +0100, Miklos Szeredi
On 11/28/18 12:03 PM, Vivek Goyal wrote:
On Wed, Nov 28, 2018 at 11:00:09AM +0100, Miklos Szeredi wrote:
On Tue, Nov 27, 2018 at 10:05 PM Vivek Goyal wrote:
On Tue, Nov 27, 2018 at 08:58:06PM +0100, Miklos Szeredi wrote:
[resending with fixed email address for Paul Moore]
Moving discussion
On 11/28/18 12:03 PM, Vivek Goyal wrote:
On Wed, Nov 28, 2018 at 11:00:09AM +0100, Miklos Szeredi wrote:
On Tue, Nov 27, 2018 at 10:05 PM Vivek Goyal wrote:
On Tue, Nov 27, 2018 at 08:58:06PM +0100, Miklos Szeredi wrote:
[resending with fixed email address for Paul Moore]
Moving discussion
On Wed, Nov 28, 2018 at 11:00:09AM +0100, Miklos Szeredi wrote:
> On Tue, Nov 27, 2018 at 10:05 PM Vivek Goyal wrote:
> >
> > On Tue, Nov 27, 2018 at 08:58:06PM +0100, Miklos Szeredi wrote:
> > > [resending with fixed email address for Paul Moore]
> > >
> > > Moving discussion from github[1] to
On Wed, Nov 28, 2018 at 11:00:09AM +0100, Miklos Szeredi wrote:
> On Tue, Nov 27, 2018 at 10:05 PM Vivek Goyal wrote:
> >
> > On Tue, Nov 27, 2018 at 08:58:06PM +0100, Miklos Szeredi wrote:
> > > [resending with fixed email address for Paul Moore]
> > >
> > > Moving discussion from github[1] to
On Tue, Nov 27, 2018 at 10:05 PM Vivek Goyal wrote:
>
> On Tue, Nov 27, 2018 at 08:58:06PM +0100, Miklos Szeredi wrote:
> > [resending with fixed email address for Paul Moore]
> >
> > Moving discussion from github[1] to here.
> >
> > To summarize: commit 007ea44892e6 ("ovl: relax permission
On Tue, Nov 27, 2018 at 10:05 PM Vivek Goyal wrote:
>
> On Tue, Nov 27, 2018 at 08:58:06PM +0100, Miklos Szeredi wrote:
> > [resending with fixed email address for Paul Moore]
> >
> > Moving discussion from github[1] to here.
> >
> > To summarize: commit 007ea44892e6 ("ovl: relax permission
On Tue, Nov 27, 2018 at 08:58:06PM +0100, Miklos Szeredi wrote:
> [resending with fixed email address for Paul Moore]
>
> Moving discussion from github[1] to here.
>
> To summarize: commit 007ea44892e6 ("ovl: relax permission checking on
> underlying layers") was added in 4.20-rc1 to make
On Tue, Nov 27, 2018 at 08:58:06PM +0100, Miklos Szeredi wrote:
> [resending with fixed email address for Paul Moore]
>
> Moving discussion from github[1] to here.
>
> To summarize: commit 007ea44892e6 ("ovl: relax permission checking on
> underlying layers") was added in 4.20-rc1 to make
[resending with fixed email address for Paul Moore]
Moving discussion from github[1] to here.
To summarize: commit 007ea44892e6 ("ovl: relax permission checking on
underlying layers") was added in 4.20-rc1 to make overlayfs access
checks on underlying "real" filesystems more consistent. The
[resending with fixed email address for Paul Moore]
Moving discussion from github[1] to here.
To summarize: commit 007ea44892e6 ("ovl: relax permission checking on
underlying layers") was added in 4.20-rc1 to make overlayfs access
checks on underlying "real" filesystems more consistent. The
Moving discussion from github[1] to here.
To summarize: commit 007ea44892e6 ("ovl: relax permission checking on
underlying layers") was added in 4.20-rc1 to make overlayfs access
checks on underlying "real" filesystems more consistent. The
discussion leading up to this commit can be found at
Moving discussion from github[1] to here.
To summarize: commit 007ea44892e6 ("ovl: relax permission checking on
underlying layers") was added in 4.20-rc1 to make overlayfs access
checks on underlying "real" filesystems more consistent. The
discussion leading up to this commit can be found at
82 matches
Mail list logo
