[lxc-devel] [PATCH] Remove MAKEDEV call, add autodev hooks, add environment variables for hook scripts.

Michael H. Warfield mhw at WittsEnd.com
Tue Mar 12 22:12:16 UTC 2013


Hey all.

On Tue, 2013-03-12 at 15:55 -0500, Serge Hallyn wrote:
> Quoting Ward, David - 0663 - MITLL (david.ward at ll.mit.edu):
> > Michael, Serge,
> > 
> > On 01/09/2013 03:38 PM, Michael H. Warfield wrote:
> > >4) clearenv and putenv( "container=lxc" ) calls were moved to just after
> > >the "start" hook in the container just prior to actually firing up the
> > >container so we could use environment variables prior to that and have
> > >them flushed them before firing up init.  Nice side effect is that you
> > >can define environment variables and then call lxc-start and have them
> > >show up in those hooks scripts.
> > 
> > Since the call to clearenv() was moved to do_start(), it also gets
> > called when running lxc-execute.  If I set up a very simple
> > container with only utsname/network namespaces, and do:
> > 
> >    lxc-execute -n $CONTAINER -- bash
> > 
> > then the PATH and HOME environment variables are no longer
> > propagated into new shell, for example.  (In Fedora at least, these
> > environment variables are set in /etc/profile, which does not get
> > sourced by /etc/bashrc or ~/.bashrc by default.)
> > 
> > Is this the desired behavior for lxc-execute now, or was it an
> > unintended side-effect?  Also keep in mind that if I do:
> > 
> >    lxc-attach -n $CONTAINER -- bash
> > 
> > the environment variables are not cleared there before opening the
> > shell (regardless of whether the container was started with
> > lxc-start or lxc-execute)...this may need to be adjusted.

> Hi,

> good question.  I mean yes that was what we were thinking, but that
> doesn't mean it's the right thing.  lxc-execute means "set up this
> container with a dummy init and run this task in it."  I personally
> think that should mean a clear environment as set up by a shell in
> the container, but I don't use lxc-execute and my opinion shouldn't
> mean much.

> Others?

I seem to recall some light discussion over some of these points before
we made the changes.  Part of that discussion even included some ideas
that we may want to configure environment variables we would pass into
the container environment.

Some variables could make sense while others not so much.  If you are
mapping into a different rootfs, how are you sure ${HOME} from the host
is going map properly into the guest or if the ${PATH} variable is
appropriate for in that container.  There's a whole lot of LD* varables
and LIB* variables that could come into play.

PIDs and named sockets could be problematical or useless.   I'm thinking
here about the ssh-authd and it's gnugp equivalent where the pids and
pipes would make no sense (and potentially open up problems).  Other
things, such as TZ, LANG, terminal values or various application
specific variables could make sense.

OTOH...  Is "leaking" those variables from the host environment into a
container environment such a good idea (I'm thinking of attach here).
If you're running a Fedora container on an Ubuntu host?  The binaries
you are running are in the context and retrieved from the container
space but the environment is inherited from the host space.

I also seem to recall that some of the more recent patches over the last
couple of months had to do with even determining your shell where NSS is
incompatible between the container and the host.  Mixing the environment
variables adds more of a chance of unexpected side-effects, wouldn't it?

The fact that this resulted in a behavior change in lxc-execute is
unexpected.  The fact that it didn't change lxc-attach raises questions
of consistency.

Thinking of "sudo" for a moment, it allows for defining what set of
environment variables it allows to pass in the environment and I seem to
recall at least a passing mention of that and whether there would be
circumstances under which you would want to do that.  Seems there maybe.
I would think we would want to control those circumstances, however.

The specific case in question (that of loading values from /etc/profile)
raises a bit of a point.  /etc/profile (and /etc/profile.d/) get loaded
by a login shell.  Other things are certainly not set up correctly
within that container wrt a login shell (wtmp, tty, etc).

It's not a clean simple question when you're crossing boundaries like
that.

> -serge


-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20130312/fdf2c4e4/attachment.pgp>


More information about the lxc-devel mailing list