[systemd-devel] [PATCH] virt: fix container detection when we're not PID 1

Lennart Poettering lennart at poettering.net
Wed Dec 10 06:22:19 PST 2014

On Wed, 10.12.14 13:52, Jan Synacek (jsynacek at redhat.com) wrote:

> Lennart Poettering <lennart at poettering.net> writes:
> > On Wed, 10.12.14 09:21, Jan Synacek (jsynacek at 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.

Well, systemd when running as PID 1 tries hard to pass a fully cleaned
up environment to system services, so that they always run in the same
clean execution environment. Checking $container of your own process
will hence generally not work unless you do it from PID 1 -- if you
booted with systemd as PID 1. Moreover we really should have a way to
detect containers even if some process way down the tree cleans up the
environment, which many processes actually do.

Then, something not to ignore: $container can be set by an
unprivileged user for any process it launches. Thus, you can
relatively easily programs about the execution context they are
running in, which is particularly dangerous for SUID programs (see the
whole discussion around secure_getenv() regarding this). Hence I am a
lot more comfortable with checking /run/systemd/container and
/proc/1/environ, since neither is fakeable without privileges.

Hope that makese sense,


Lennart Poettering, Red Hat

More information about the systemd-devel mailing list