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
[email protected]
https://lists.sourceforge.net/lists/listinfo/lxc-devel
