[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <110d7813-a756-a90d-ef2d-e496785cb6b1@fingolfin.org>
Date: Tue, 29 Sep 2020 16:01:09 -0700
From: Robert Mustacchi <rm@...golfin.org>
To: libc-coord@...ts.openwall.com, Ariadne Conill <ariadne@...eferenced.org>
Subject: Re: [RFC] Add posix_spawnattr_chroot_np()
Hi Ariadne,
On 9/29/20 1:38 PM, Ariadne Conill wrote:
> Hello,
>
> Package managers frequently have a feature where you can use the package
> manager to build a new filesystem image in a sub-directory (usually
> exposed as the --root option in the package manager). However, to
> achieve this, we have to be able to chroot into the sub-directory to run
> maintainer scripts.
>
> Right now, package managers usually do fork() + chroot() + execve() to
> implement this. I find it desirable to migrate apk from this fork() +
> chroot() + execve() pattern toward using posix_spawn() as that allows
> for the underlying libc to take care of spawning the maintainer scripts
> for us (and I assume posix_spawn() will always use the most efficient
> method available for doing so).
>
> Accordingly, I propose adding the following interface:
>
> int posix_spawnattr_chroot_np(posix_spawnattr_t *attr, const char *chroot);
>
> This will, of course, set a chroot attribute in posix_spawnattr_t.
>
> Like the other interfaces, it will return 0 or an appropriate error number.
>
> Doing so would allow us to migrate maintainer script handling in package
> managers to use posix_spawn, at least in apk this is the only missing
> functionality we require.
This seems like it could be a useful thing for folks and makes sense as
something to add. Thanks for writing this up. A couple of questions
about the proposal:
* Semantically would one expect that the "path" argument (as POSIX calls
it in
https://pubs.opengroup.org/onlinepubs/007904975/functions/posix_spawn.html)
to be located within the chroot? I'd imagine so?
* When does the chroot occur with respect to the open actions taking
place? Does one process all file actions before or after the chroot
takes place or does this need to be interleaved in the file actions to
give consumers more flexibility?
* What are the expectations if multiple calls to
posix_spawnattr_chroot_np() are made? Is it expected that they all must
apply or that only the last one applies? Does passing NULL for a path
effectively un-set a chroot request?
* Presumably an implementation is allowed to return the errno of a
failed chroot(), similar to what happens with fork(), exec(), etc. and
should not continue on.
> I plan on introducing this to musl shortly if there is consensus that
> the proposed interface is acceptable. I can also contribute a glibc
> implementation and FreeBSD libc implementation if that would be helpful.
If that ends up happening, I can do an illumos implementation.
Robert
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
