> On Sep 9, 2019, at 2:18 AM, Mickaël Salaün wrote:
>
>
>> On 06/09/2019 20:41, Andy Lutomirski wrote:
>>
>>
On Sep 6, 2019, at 11:38 AM, Jeff Layton wrote:
> On Fri, 2019-09-06 at 19:14 +0200, Mickaël Salaün wrote:
>> On 06/09/2019 18:48, Jeff Layton wrote:
>>> On Fr
On 09/09/2019 14:28, Aleksa Sarai wrote:
> On 2019-09-09, Mickaël Salaün wrote:
>> On 09/09/2019 12:12, James Morris wrote:
>>> On Mon, 9 Sep 2019, Mickaël Salaün wrote:
As I said, O_MAYEXEC should be ignored if it is not supported by the
kernel, which perfectly fit with the current op
On 09/09/2019 13:54, Aleksa Sarai wrote:
> On 2019-09-09, Mickaël Salaün wrote:
>> On 06/09/2019 21:03, James Morris wrote:
>>> On Fri, 6 Sep 2019, Jeff Layton wrote:
>>>
The fact that open and openat didn't vet unknown flags is really a bug.
Too late to fix it now, of course, and
On 2019-09-09, Mickaël Salaün wrote:
> On 09/09/2019 12:12, James Morris wrote:
> > On Mon, 9 Sep 2019, Mickaël Salaün wrote:
> >> As I said, O_MAYEXEC should be ignored if it is not supported by the
> >> kernel, which perfectly fit with the current open(2) flags behavior, and
> >> should also beh
On 2019-09-09, Mickaël Salaün wrote:
> On 06/09/2019 21:03, James Morris wrote:
> > On Fri, 6 Sep 2019, Jeff Layton wrote:
> >
> >> The fact that open and openat didn't vet unknown flags is really a bug.
> >>
> >> Too late to fix it now, of course, and as Aleksa points out, we've
> >> worked aroun
On 09/09/2019 12:12, James Morris wrote:
> On Mon, 9 Sep 2019, Mickaël Salaün wrote:
>
>>
>> On 06/09/2019 21:03, James Morris wrote:
>>> On Fri, 6 Sep 2019, Jeff Layton wrote:
>>>
The fact that open and openat didn't vet unknown flags is really a bug.
Too late to fix it now, of co
On Mon, 9 Sep 2019, Mickaël Salaün wrote:
>
> On 06/09/2019 21:03, James Morris wrote:
> > On Fri, 6 Sep 2019, Jeff Layton wrote:
> >
> >> The fact that open and openat didn't vet unknown flags is really a bug.
> >>
> >> Too late to fix it now, of course, and as Aleksa points out, we've
> >> work
On 06/09/2019 22:06, Andy Lutomirski wrote:
>
>
>> On Sep 6, 2019, at 12:43 PM, Jeff Layton wrote:
>>
>>> On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
On 2019-09-06, Jeff Layton wrote:
> On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
>> On 06/09/2019 17:56, Flor
On 06/09/2019 21:03, James Morris wrote:
> On Fri, 6 Sep 2019, Jeff Layton wrote:
>
>> The fact that open and openat didn't vet unknown flags is really a bug.
>>
>> Too late to fix it now, of course, and as Aleksa points out, we've
>> worked around that in the past. Now though, we have a new open
On 06/09/2019 20:41, Andy Lutomirski wrote:
>
>
>> On Sep 6, 2019, at 11:38 AM, Jeff Layton wrote:
>>
>>> On Fri, 2019-09-06 at 19:14 +0200, Mickaël Salaün wrote:
On 06/09/2019 18:48, Jeff Layton wrote:
> On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
>> On 06/09/2019 17:5
On 2019-09-07, Aleksa Sarai wrote:
> On 2019-09-06, Jeff Layton wrote:
> > On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> > > On 2019-09-06, Jeff Layton wrote:
> > > > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > >
On 2019-09-06, Jeff Layton wrote:
> On Fri, 2019-09-06 at 13:06 -0700, Andy Lutomirski wrote:
> > > On Sep 6, 2019, at 12:43 PM, Jeff Layton wrote:
> > >
> > > > On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> > > > > On 2019-09-06, Jeff Layton wrote:
> > > > > > On Fri, 2019-09-06 at
On 2019-09-06, Jeff Layton wrote:
> On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> > On 2019-09-06, Jeff Layton wrote:
> > > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > > Let's assume I want to add support for this
> On Sep 6, 2019, at 1:51 PM, Jeff Layton wrote:
>
> On Fri, 2019-09-06 at 13:06 -0700, Andy Lutomirski wrote:
>
>> I’m not at all convinced that the kernel needs to distinguish all these, but
>> at least upgradability should be its own thing IMO.
>
> Good point. Upgradability is definitely ortho
On Fri, 2019-09-06 at 13:06 -0700, Andy Lutomirski wrote:
> > On Sep 6, 2019, at 12:43 PM, Jeff Layton wrote:
> >
> > > On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> > > > On 2019-09-06, Jeff Layton wrote:
> > > > > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > > > >
> On Sep 6, 2019, at 12:43 PM, Jeff Layton wrote:
>
>> On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
>>> On 2019-09-06, Jeff Layton wrote:
On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> On 06/09/2019 17:56, Florian Weimer wrote:
> Let's assume I want to add s
On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> On 2019-09-06, Jeff Layton wrote:
> > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > Let's assume I want to add support for this to the glibc dynamic loader,
> > > > while st
On Fri, 6 Sep 2019, Jeff Layton wrote:
> The fact that open and openat didn't vet unknown flags is really a bug.
>
> Too late to fix it now, of course, and as Aleksa points out, we've
> worked around that in the past. Now though, we have a new openat2
> syscall on the horizon. There's little need
On Fri, Sep 06, 2019 at 08:27:31PM +0200, Florian Weimer wrote:
> * Tycho Andersen:
>
> > On Fri, Sep 06, 2019 at 07:20:51PM +0200, Christian Brauner wrote:
> >> On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote:
> >> > On 2019-09-06, Mickaël Salaün wrote:
> >> > >
> >> > > On 06/09/2
* Jeff Layton:
> Even better would be to declare the new flag in some openat2-only flag
> space, so there's no confusion about it being supported by legacy open
> calls.
Isn't that desirable anyway because otherwise fcntl with F_GETFL will
give really confusing results?
> If glibc wants to imple
> On Sep 6, 2019, at 11:38 AM, Jeff Layton wrote:
>
>> On Fri, 2019-09-06 at 19:14 +0200, Mickaël Salaün wrote:
>>> On 06/09/2019 18:48, Jeff Layton wrote:
On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> On 06/09/2019 17:56, Florian Weimer wrote:
> Let's assume I want t
On Fri, 2019-09-06 at 19:14 +0200, Mickaël Salaün wrote:
> On 06/09/2019 18:48, Jeff Layton wrote:
> > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > Let's assume I want to add support for this to the glibc dynamic loader,
> > > > w
* Tycho Andersen:
> On Fri, Sep 06, 2019 at 07:20:51PM +0200, Christian Brauner wrote:
>> On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote:
>> > On 2019-09-06, Mickaël Salaün wrote:
>> > >
>> > > On 06/09/2019 17:56, Florian Weimer wrote:
>> > > > Let's assume I want to add support f
On Fri, Sep 06, 2019 at 07:20:51PM +0200, Christian Brauner wrote:
> On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote:
> > On 2019-09-06, Mickaël Salaün wrote:
> > >
> > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > Let's assume I want to add support for this to the glibc dynam
On 06/09/2019 19:20, Christian Brauner wrote:
> On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote:
>> On 2019-09-06, Mickaël Salaün wrote:
>>>
>>> On 06/09/2019 17:56, Florian Weimer wrote:
Let's assume I want to add support for this to the glibc dynamic loader,
while still
On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote:
> On 2019-09-06, Mickaël Salaün wrote:
> >
> > On 06/09/2019 17:56, Florian Weimer wrote:
> > > Let's assume I want to add support for this to the glibc dynamic loader,
> > > while still being able to run on older kernels.
> > >
> > >
On 06/09/2019 18:48, Jeff Layton wrote:
> On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
>> On 06/09/2019 17:56, Florian Weimer wrote:
>>> Let's assume I want to add support for this to the glibc dynamic loader,
>>> while still being able to run on older kernels.
>>>
>>> Is it safe to t
On 2019-09-06, Jeff Layton wrote:
> On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > On 06/09/2019 17:56, Florian Weimer wrote:
> > > Let's assume I want to add support for this to the glibc dynamic loader,
> > > while still being able to run on older kernels.
> > >
> > > Is it safe t
On 2019-09-06, Mickaël Salaün wrote:
>
> On 06/09/2019 17:56, Florian Weimer wrote:
> > Let's assume I want to add support for this to the glibc dynamic loader,
> > while still being able to run on older kernels.
> >
> > Is it safe to try the open call first, with O_MAYEXEC, and if that fails
> >
On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> On 06/09/2019 17:56, Florian Weimer wrote:
> > Let's assume I want to add support for this to the glibc dynamic loader,
> > while still being able to run on older kernels.
> >
> > Is it safe to try the open call first, with O_MAYEXEC, and
On 06/09/2019 17:56, Florian Weimer wrote:
> Let's assume I want to add support for this to the glibc dynamic loader,
> while still being able to run on older kernels.
>
> Is it safe to try the open call first, with O_MAYEXEC, and if that fails
> with EINVAL, try again without O_MAYEXEC?
The ker
Let's assume I want to add support for this to the glibc dynamic loader,
while still being able to run on older kernels.
Is it safe to try the open call first, with O_MAYEXEC, and if that fails
with EINVAL, try again without O_MAYEXEC?
Or do I risk disabling this security feature if I do that?
D
When the O_MAYEXEC flag is passed, sys_open() may be subject to
additional restrictions depending on a security policy implemented by an
LSM through the inode_permission hook.
The underlying idea is to be able to restrict scripts interpretation
according to a policy defined by the system administr
33 matches
Mail list logo
