[lxc-devel] [PATCH v2 1/2] Add option to lxc-attach to select specific namespaces
Christian Seiler
christian at iwakd.de
Tue May 22 14:10:25 UTC 2012
Hi Serge,
> Note that for now the same thing will happen with pid. I don't think
> CLONE_NEWUSER needs to be special cased. Likewise, someone may want
> to use this lxc on an older kernel without any setns support at all.
I'm not sure this is wise: Currently, kernel 3.0 supports all
namespaces
except pid, mount and user for setns(). Since user namespaces are not
very well supported in general, lxc-start currently does not even set
one up when starting a container.
Therefore, I think the correct logic should be the following:
* If the namespace is used by lxc-start when clone()ing to initialize
a container, FAIL if one wants to attach without specifying partial
namespaces. This follows the principle of least surprise: lxc-attach
without parameters will either work and one is completely attached
or it will fail.
For those administrators who don't care about pid/mount namespaces
on current vanilla kernels but want to do partial attachments, the
-s flag still allows for that.
* If lxc-start does not use the namespace (currently only user
namespaces), still try to attach to it, (making lxc-attach
future-proof) but ignore any failure since it doesn't really matter
if it fails as long as user namespaces aren't used by lxc-start.
Thoughts?
> Your choices for behavior are good (print a msg for which == -1,
> and error out if the namespace was specially chosen), but I think
> you should simply do it for all namespaces.
Actually, ERROR() just prints an error message, but does not terminate
the
program, (the only difference between ERROR and DEBUG is that ERROR
will be
seen on stderr by default, for DEBUG you need a log file) so missing
user
namespaces will not cause the program to terminate. But thinking about
it,
it's probably better if it did, because if the user explicitly
requested it,
this should really be an error condition. I'll update the patch.
Regards,
Christian
More information about the lxc-devel
mailing list