[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cd33f827-203e-bae2-f993-8b5116a8eea4@dereferenced.org>
Date: Tue, 29 Sep 2020 20:07:13 -0600
From: Ariadne Conill <ariadne@...eferenced.org>
To: Robert Mustacchi <rm@...golfin.org>, libc-coord@...ts.openwall.com
Subject: Re: [RFC] Add posix_spawnattr_chroot_np()
Helo,
On 2020-09-29 17:01, Robert Mustacchi wrote:
> 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?
Yes, the path argument should be relative to the chroot.
> * 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?
I haven't thought about this, but I think having the chroot happen prior
to the file actions makes most sense.
> * 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?
I think it should only be the last one, at least that is what I planned
to do. And yes, NULL should unset 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.
This seems agreeable to me.
>> 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.
Yes, I will be working on that in a few days once there is clear consensus.
I should mention that we should probably have this as
posix_spawnattr_[set|get]chroot_np, like the other interfaces have.
This thread was more about the actual semantics though.
Ariadne
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.
