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.w...@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
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
