From: David Laight <David.Laight@ACULAB.COM>
To: 'Andy Lutomirski' <luto@kernel.org>,
"Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>,
LKML <linux-kernel@vger.kernel.org>, Jann Horn <jann@thejh.net>,
Christian Brauner <christian.brauner@canonical.com>
Subject: RE: forkat(int pidfd), execveat(int pidfd), other awful things?
Date: Tue, 2 Feb 2021 09:23:54 +0000 [thread overview]
Message-ID: <cf07f0732eb94dbfa67c9d56ceba738e@AcuMS.aculab.com> (raw)
In-Reply-To: <CALCETrVGLx5yeHo7ExAmJZmPjVjcJiV7p1JOa4iUaW5DRoEvLQ@mail.gmail.com>
From: Andy Lutomirski
> Sent: 01 February 2021 18:30
...
> 2. A sane process creation API. It would be delightful to be able to
> create a fully-specified process without forking. This might end up
> being a fairly complicated project, though -- there are a lot of
> inherited process properties to be enumerated.
Since you are going to (eventually) load in a program image
have to do several system calls to create the process isn't
likely to be a problem.
So using separate calls for each property isn't really an issue
and solves the horrid problem of the API structure.
So you could create an embryonic process that inherits a lot
of stuff from the current process, the do actions that
sort out the fds, argv, namespace etc.
Finally running the new program.
It would probably make implement posix_spawn() easier.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2021-02-02 9:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-01 17:47 forkat(int pidfd), execveat(int pidfd), other awful things? Jason A. Donenfeld
2021-02-01 17:51 ` Jason A. Donenfeld
2021-02-01 18:20 ` Christian Brauner
2021-02-01 18:29 ` Andy Lutomirski
2021-02-02 9:23 ` David Laight [this message]
2021-07-28 16:37 ` Leveraging pidfs for process creation without fork John Cotton Ericson
2021-07-29 14:24 ` Christian Brauner
2021-07-29 14:54 ` John Ericson
2021-07-30 1:41 ` Al Viro
2021-07-31 22:11 ` John Ericson
2021-07-31 22:42 ` Al Viro
2021-08-02 12:19 ` Christian Brauner
2021-08-03 6:00 ` John Cotton Ericson
2021-02-01 18:32 ` forkat(int pidfd), execveat(int pidfd), other awful things? Casey Schaufler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cf07f0732eb94dbfa67c9d56ceba738e@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=Jason@zx2c4.com \
--cc=christian.brauner@canonical.com \
--cc=jann@thejh.net \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.