On Wed, 10.12.14 13:52, Jan Synacek (jsyna...@redhat.com) 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.

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
systemd-devel mailing list

Reply via email to