[systemd-devel] [PATCH 1/2] nspawn: --populate to run static binaries on empty target directory

Shawn Landden shawn at churchofgit.com
Tue Dec 3 07:45:18 PST 2013


On Mon, Dec 2, 2013 at 9:41 AM, Shawn Landden <shawn at churchofgit.com> wrote:
> On Mon, Dec 2, 2013 at 8:27 AM, Lennart Poettering
> <lennart at poettering.net> wrote:
>> On Sat, 30.11.13 10:20, Shawn Landden (shawn at churchofgit.com) wrote:
>>
>>> nspawn has been called "chroot on steroids".
>>>
>>> Continue that tradition by supporting target directories that
>>> are not root directories.
>>>
>>> This patch handles the simple case: a static binary.
>>
>> Hmm, I am not sure how I feel about this. This appears a bit too
>> specific for me, and given the requirement for static binaries this is
>> also so limited.
> The next patch is the series adds support for dynamic libraries. This patch
> also doesn't need bind mounts, and it executes through /proc/self/fd/%n, but
> support for one-file scripts and dynamic libraries in the next patch does
> require bind mounts. I feel you don't really understand my patch. :/
> I'll sum up what I'm doing:
>
> If --populate is passed, analyze the executable, which opens it and set the
> exec path to /proc/self/fd/%n. If executable is static this is all you
> have to do.
>
> If it has a shebang, analyze that. If either the shebang or executable
> is dynamic,
> test if the linker is the GNU linker, and if it is have the linker
> tell use what libraries the
> executable needs. Then bind mount the linker, shebang (if there is one), and
> libraries into the target.
>
> Unmount these when the machine shuts down.
>>
>> I wonder if we can find a different way to support this, without adding
>> high-level switches to nspawn itself.
>>
>> For example, couldn't extending "--bind=" a bit to also support bind
>> mounting files (in contrast to just directories the way it currently
>> does) already gets us 90% of the way? And then do the rest 10% by adding
>> an example how to use this to bind mount static binaries from the host
>> into the container to the example in the man page? Allowing bind
>> mounting of files has been on the TODO list for a while anyway...
I'll add a bind mount file feature, and then rebase the second patch
on top of that.
>>
>> Something like:
>>
>> # systemd-nspawn -D /srv/mycontainer --bind=/usr/bin/populate-container:/tmp/populate-container /tmp/populate-container
>>
>> This of course wouldn't check if the file executed is staticall linked,
>> but the user should quickly get an error about missing .sos if it isn't?
> No, the linker would be missing, and the user would get "execvpe()
> failed: No such file or directory",
> which is confusing.
>>
>>>          assert_se(sigemptyset(&mask) == 0);
>>> @@ -1164,7 +1195,7 @@ int main(int argc, char *argv[]) {
>>>                          gid_t gid = (gid_t) -1;
>>>                          unsigned n_env = 2;
>>>                          const char *envp[] = {
>>> -                                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
>>> +                                DEFAULT_PATH_SPLIT_USR,
>>
>> This bit looks like like something we really should do though. Could you
>> isolate this out and resubmit, please?
>
>>
>>> +#define DEFAULT_PATH_SPLIT_USR "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
>>> +
>>>  #ifdef HAVE_SPLIT_USR
>>> -#  define DEFAULT_PATH "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
>>> +#  define DEFAULT_PATH DEFAULT_PATH_SPLIT_USR
>>>  #else
>>>  #  define DEFAULT_PATH "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"
>>>  #endif
>>> @@ -51,6 +53,7 @@ int path_is_mount_point(const char *path, bool allow_symlink);
>>>  int path_is_read_only_fs(const char *path);
>>>  int path_is_os_tree(const char *path);
>>
>> And this too, of course...
>>
>> Lennart
>>
>> --
>> Lennart Poettering, Red Hat
>> _______________________________________________
>> systemd-devel mailing list
>> systemd-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/systemd-devel


More information about the systemd-devel mailing list