Hi, > It doesn't come across as negative - it comes across as suggesting > we need a list or matrix of use cases and to decide what to do in > each case.
Ok, then I might want to start with some ideas thrown in: - lxc-attach with shell clear env + container=lxc only when doing getent lookup logic, default PATH just for getent call BUT don't pass it to shell because it will probably read some defaults anyway - lxc-attach with program name clear env + container=lxc + default PATH (see below) - lxc-attach with only partial namespaces always set container= probably (?) keep env but set container=lxc (any process that setsid()s away drags baggage into the container anyway) - if -s MOUNT maybe sanitize PATH and LD_LIBRARY_PATH additionally (LD_LIBRARY_PATH empty, PATH to defaults below) but DON'T touch other variables - probably: add option to override defaults if wanted, i.e. on partial attach clean anyway or on full attach keep in anyway - probably: add option to set specific environment variables -v PATH=... -v LD_LIBRARY_PATH=... regardless of other options - other options should not make any difference Default PATH: /usr/local/bin:/usr/bin:/bin probably safe bet + .../sbin maybe if uid inside container is 0, also add those Thoughts? -- Christian ------------------------------------------------------------------------------ Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel