Date: Tue, 13 Oct 2020 10:40:29 -0400 From: Rich Felker <dalias@...c.org> To: libc-coord@...ts.openwall.com Cc: Ariadne Conill <ariadne@...eferenced.org> Subject: Re: [RFC] Add posix_spawnattr_chroot_np() On Tue, Sep 29, 2020 at 04:01:09PM -0700, 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? > > * 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? I don't like that this is storing unbounded-size state in the attribute object, and the obvious solution to the first question (and the second) is that chroot should not be an attribute but a file action, the same way chdir (newly added) is. Rich
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.