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

[Ward, David - 0663 - MITLL]

On 03/12/2013 06:12 PM, Michael H. Warfield wrote:
> 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.

It sounds like this was not a completely unintentional side-effect 
then.  I agree that there are many reasons we may not want environment 
variables to propagate into a container.  It's easy enough to source 
/etc/profile in my example, compared to the challenges in dealing with 
the other cases.

With respect to "sudo", if you pass it the "-E" flag, it will not clear 
your environment variables...  does it make sense to have a similar flag 
for lxc-execute and lxc-attach?  (And I would think the default behavior 
for lxc-attach should also be to clear the environment variables.)

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4571 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20130312/b1b0d495/attachment.bin>