On Mon, Apr 29, 2019 at 07:31:43PM +0200, Enrico Weigelt, metux IT consult
wrote:
Argh. Sorry, it seems your emails aren't making it into my inbox, only
my once-in-a-long-while-checked lkml folder. Sorry again.
> On 29.04.19 17:49, Serge E. Hallyn wrote:
>
> >> * all users are equal - no
* Linus Torvalds:
> On Tue, Apr 30, 2019 at 9:19 AM Linus Torvalds
> wrote:
>>
>> Of course, if you *don't* need the exact vfork() semantics, clone
>> itself actually very much supports a callback model with s separate
>> stack. You can basically do this:
>>
>> - allocate new stack for the
On Tue, Apr 30, 2019 at 5:39 AM Oleg Nesterov wrote:
>
> Yes, but I am wondering if man vfork should clarify what "child terminates"
> actually means. I mean, the child can do clone(CLONE_THREAD) + sys_exit(),
> this will wake the parent thread up before the child process exits or execs.
That
On Tue, Apr 30, 2019 at 9:19 AM Linus Torvalds
wrote:
>
> Of course, if you *don't* need the exact vfork() semantics, clone
> itself actually very much supports a callback model with s separate
> stack. You can basically do this:
>
> - allocate new stack for the child
> - in trivial asm
On Tue, Apr 30, 2019 at 1:21 AM Florian Weimer wrote:
>
> > (In fact, if I recall correctly, the _reason_ we have an explicit
> > 'vfork()' entry point rather than using clone() with magic parameters
> > was that the lack of arguments meant that you didn't have to
> > save/restore any registers
On 04/29, Linus Torvalds wrote:
>
> Linux vfork() is very much a real vfork(). What do you mean?
Yes, but I am wondering if man vfork should clarify what "child terminates"
actually means. I mean, the child can do clone(CLONE_THREAD) + sys_exit(),
this will wake the parent thread up before the
* Linus Torvalds:
> Note that vfork() is "exciting" for the compiler in much the same way
> "setjmp/longjmp()" is, because of the shared stack use in the child
> and the parent. It is *very* easy to get this wrong and cause massive
> and subtle memory corruption issues because the parent returns
* Linus Torvalds:
> On Mon, Apr 29, 2019 at 1:38 PM Florian Weimer wrote:
>>
>> In Linux-as-the-ABI (as opposed to Linux-as-the-implementation), vfork
>> is sometimes implemented as fork, so applications cannot rely on the
>> vfork behavior regarding the stopped parent and the shared address
>>
On Mon, Apr 29, 2019 at 5:39 PM Jann Horn wrote:
>
> ... uuuh, whoops. Turns out I don't know what I'm talking about.
Well, apparently there's some odd libc issue accoprding to Florian, so
there *might* be something to it.
> Nevermind. For some reason I thought vfork() was just
>
On Mon, Apr 29, 2019 at 4:21 PM Linus Torvalds
wrote:
>
> On Mon, Apr 29, 2019 at 12:55 PM Jann Horn wrote:
> >
> > ... I guess that already has a name, and it's called vfork(). (Well,
> > except that the Linux vfork() isn't a real vfork().)
>
> What?
>
> Linux vfork() is very much a real
On Mon, Apr 29, 2019 at 1:38 PM Florian Weimer wrote:
>
> In Linux-as-the-ABI (as opposed to Linux-as-the-implementation), vfork
> is sometimes implemented as fork, so applications cannot rely on the
> vfork behavior regarding the stopped parent and the shared address
> space.
What broken
On Mon, Apr 29, 2019 at 10:50 PM Florian Weimer wrote:
>
> * Jann Horn:
>
> >> int clone_temporary(int (*fn)(void *arg), void *arg, pid_t *child_pid,
> >> )
> >>
> >> and then you'd use it like this to fork off a child process:
> >>
> >> int spawn_shell_subprocess_(void *arg) {
> >> char
* Jann Horn:
>> int clone_temporary(int (*fn)(void *arg), void *arg, pid_t *child_pid,
>> )
>>
>> and then you'd use it like this to fork off a child process:
>>
>> int spawn_shell_subprocess_(void *arg) {
>> char *cmdline = arg;
>> execl("/bin/sh", "sh", "-c", cmdline);
>> return -1;
>> }
On Mon, Apr 29, 2019 at 10:38 PM Florian Weimer wrote:
>
> * Linus Torvalds:
>
> > On Mon, Apr 29, 2019 at 12:55 PM Jann Horn wrote:
> >>
> >> ... I guess that already has a name, and it's called vfork(). (Well,
> >> except that the Linux vfork() isn't a real vfork().)
> >
> > What?
> >
> >
* Linus Torvalds:
> On Mon, Apr 29, 2019 at 12:55 PM Jann Horn wrote:
>>
>> ... I guess that already has a name, and it's called vfork(). (Well,
>> except that the Linux vfork() isn't a real vfork().)
>
> What?
>
> Linux vfork() is very much a real vfork(). What do you mean?
In Linux-as-the-ABI
On Mon, Apr 29, 2019 at 12:55 PM Jann Horn wrote:
>
> ... I guess that already has a name, and it's called vfork(). (Well,
> except that the Linux vfork() isn't a real vfork().)
What?
Linux vfork() is very much a real vfork(). What do you mean?
Linus
On Mon, Apr 29, 2019 at 3:30 PM Jann Horn wrote:
> On Sat, Apr 20, 2019 at 3:14 AM Kevin Easton wrote:
> > On Mon, Apr 15, 2019 at 01:29:23PM -0700, Andy Lutomirski wrote:
> > > On Mon, Apr 15, 2019 at 12:59 PM Aleksa Sarai wrote:
> > > >
> > > > On 2019-04-15, Enrico Weigelt, metux IT consult
On Sat, Apr 20, 2019 at 3:14 AM Kevin Easton wrote:
> On Mon, Apr 15, 2019 at 01:29:23PM -0700, Andy Lutomirski wrote:
> > On Mon, Apr 15, 2019 at 12:59 PM Aleksa Sarai wrote:
> > >
> > > On 2019-04-15, Enrico Weigelt, metux IT consult wrote:
> > > > > This patchset makes it possible to
On 29.04.19 17:49, Serge E. Hallyn wrote:
>> * all users are equal - no root at all. the only exception is the>>
>> initial process, which gets the kernel devices mounted into his>>
namespace.> > This does not match my understanding, but I'm most likely
wrong. (I thought> there was an actual
On Tue, Apr 16, 2019 at 08:32:50PM +0200, Enrico Weigelt, metux IT consult
wrote:
(Sorry for the late reply, I had missed this one)
> On 15.04.19 17:50, Serge E. Hallyn wrote:
>
> Hi,
>
> >> I'm working on implementing plan9-like fs namespaces, where unprivileged>>
> >> processes can change
On Mon, Apr 15, 2019 at 01:29:23PM -0700, Andy Lutomirski wrote:
> Anyway, clone(2) is an enormous mess. Surely the right solution here
> is to have a whole new process creation API that takes a big,
> extensible struct as an argument, and supports *at least* the full
> abilities of
On Sat, Apr 20, 2019 at 12:14 AM Kevin Easton wrote:
> On Mon, Apr 15, 2019 at 01:29:23PM -0700, Andy Lutomirski wrote:
> > On Mon, Apr 15, 2019 at 12:59 PM Aleksa Sarai wrote:
> > >
> > > On 2019-04-15, Enrico Weigelt, metux IT consult wrote:
> > > > > This patchset makes it possible to
On April 20, 2019 9:14:06 AM GMT+02:00, Kevin Easton wrote:
>On Mon, Apr 15, 2019 at 01:29:23PM -0700, Andy Lutomirski wrote:
>> On Mon, Apr 15, 2019 at 12:59 PM Aleksa Sarai
>wrote:
>> >
>> > On 2019-04-15, Enrico Weigelt, metux IT consult
>wrote:
>> > > > This patchset makes it possible to
On Mon, Apr 15, 2019 at 01:29:23PM -0700, Andy Lutomirski wrote:
> On Mon, Apr 15, 2019 at 12:59 PM Aleksa Sarai wrote:
> >
> > On 2019-04-15, Enrico Weigelt, metux IT consult wrote:
> > > > This patchset makes it possible to retrieve pid file descriptors at
> > > > process creation time by
On 17.04.19 14:54, Christian Brauner wrote:
>> Ah, that is a cool thing !>> I suppose that also works across namespaces ?>
>> > Yes, it should. If
you hand off the pidfd to another pidns (e.g. via SCM> credentials) for
example.
I thought about things like sending the pidfd via unix socket.
It
> On Apr 17, 2019, at 5:19 AM, Florian Weimer wrote:
>
> * Andy Lutomirski:
>
>> I would personally *love* it if distros started setting no_new_privs
>> for basically all processes.
>
> Wouldn't no_new_privs inhibit all security transitions, including those
> that reduce privileges? And
On Wed, Apr 17, 2019 at 02:03:16PM +0200, Enrico Weigelt, metux IT consult
wrote:
> On 16.04.19 23:31, Andy Lutomirski wrote:
>
> >> How exactly would the pidfd improve this scenario ?
> >> IMHO, would just need to pass the inherited fd's to that daemon (eg.
> >> via unix socket) which then sets
* Andy Lutomirski:
> I would personally *love* it if distros started setting no_new_privs
> for basically all processes.
Wouldn't no_new_privs inhibit all security transitions, including those
that reduce privileges? And therefore effectively reduce security?
> Anyway, clone(2) is an enormous
On 16.04.19 23:31, Andy Lutomirski wrote:
>> How exactly would the pidfd improve this scenario ?
>> IMHO, would just need to pass the inherited fd's to that daemon (eg.
>> via unix socket) which then sets them up in the new child process.
>
> It makes it easier to wait until the privileged
On Tue, Apr 16, 2019 at 11:46 AM Enrico Weigelt, metux IT consult
wrote:
>
> On 15.04.19 22:29, Andy Lutomirski wrote:
>
>
>
> > I would personally *love* it if distros started setting no_new_privs> for
> > basically all processes.
>
> Maybe a pam module for that would be fine.
> But this
On 15.04.19 22:29, Andy Lutomirski wrote:
> I would personally *love* it if distros started setting no_new_privs> for
> basically all processes.
Maybe a pam module for that would be fine.
But this should be configurable per-user, as so many things still rely
on suid.
Actually, I'd like to
On 15.04.19 21:59, Aleksa Sarai wrote:
> Just spit-balling -- is no_new_privs not sufficient for this usecase?> Not
> granting privileges such as setuid during execve(2) is the main>
point of that flag.
Oh, I wasn't aware of that. Thanks.
--mtx
--
Enrico Weigelt, metux IT consult
Free
On 15.04.19 17:50, Serge E. Hallyn wrote:
Hi,
>> I'm working on implementing plan9-like fs namespaces, where unprivileged>>
>> processes can change their own namespace at will. For that, certain>
> Is there any place where we can see previous discussion about this?
Yes, lkml and constainers
On Mon, Apr 15, 2019 at 2:26 PM Jonathan Kowalski wrote:
>
> On Mon, Apr 15, 2019 at 9:34 PM Andy Lutomirski wrote:
> > I would personally *love* it if distros started setting no_new_privs
> > for basically all processes. And pidfd actually gets us part of the
> > way toward a straightforward
On Mon, Apr 15, 2019 at 9:34 PM Andy Lutomirski wrote:
>
> On Mon, Apr 15, 2019 at 12:59 PM Aleksa Sarai wrote:
> >
> > On 2019-04-15, Enrico Weigelt, metux IT consult wrote:
> > > > This patchset makes it possible to retrieve pid file descriptors at
> > > > process creation time by introducing
On Mon, Apr 15, 2019 at 12:59 PM Aleksa Sarai wrote:
>
> On 2019-04-15, Enrico Weigelt, metux IT consult wrote:
> > > This patchset makes it possible to retrieve pid file descriptors at
> > > process creation time by introducing the new flag CLONE_PIDFD to the
> > > clone() system call as
On 2019-04-15, Enrico Weigelt, metux IT consult wrote:
> > This patchset makes it possible to retrieve pid file descriptors at
> > process creation time by introducing the new flag CLONE_PIDFD to the
> > clone() system call as previously discussed.
>
> Sorry, for highjacking this thread, but I'm
On Mon, Apr 15, 2019 at 12:08:09PM +0200, Enrico Weigelt, metux IT consult
wrote:
> On 14.04.19 22:14, Christian Brauner wrote:
>
> Hi folks,
>
> > This patchset makes it possible to retrieve pid file descriptors at
> > process creation time by introducing the new flag CLONE_PIDFD to the
> >
On 14.04.19 22:14, Christian Brauner wrote:
Hi folks,
> This patchset makes it possible to retrieve pid file descriptors at
> process creation time by introducing the new flag CLONE_PIDFD to the
> clone() system call as previously discussed.
Sorry, for highjacking this thread, but I'm curious
39 matches
Mail list logo
