Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 29 Sep 2020 20:07:13 -0600
From: Ariadne Conill <>
To: Robert Mustacchi <>,
Subject: Re: [RFC] Add posix_spawnattr_chroot_np()


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
> 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.


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.