On Wed, Dec 10, 2014 at 01:52:08PM +0100, Jan Synacek wrote: > Lennart Poettering <lenn...@poettering.net> writes: > > On Wed, 10.12.14 09:21, Jan Synacek (jsyna...@redhat.com) wrote: > > > >> systemd-detect-virt would print "none" when using nspawn to run a shell > >> inside a container and then running systemd-detect-virt in it, because > >> the shell would be PID 1, not the actuall systemd-detect-virt > >> process. > > > > So, previously the code read the env var directly from > > /proc/1/environ, but that file is only readable with privs, hence I > > added code to PID 1 to write the value of that env var to > > /run/systemd/container which is readable without privs. Now, if you > > run a shell as PID 1 that will obviously not happen and the detection > > won't work after all. > > > > Simply relying that $container is inherited from PID 1 down is > > something I'd really like to avoid, though. > > Could you please explain why? I don't see why that might be a problem. Because container is a completely generic name, and it is not exported to children by systemd. > > I have now made a change to the code that falls back to > > getenv_for_pid() if /rub/systemd/container does not exist. THis will > > only be ffective with perms however. The new code hence still isn't > > perfect: if you boot up with only a shell as PID 1 and drop privileges > > the code will still not be able to detect the container manager. Not > > sure what other option we have, though.
Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
