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.