Am 06.06.2013 10:08, schrieb Daniel P. Berrange:
On Thu, Jun 06, 2013 at 09:58:28AM +0200, Richard Weinberger wrote:
Am 06.06.2013 09:53, schrieb Daniel P. Berrange:
On Wed, Jun 05, 2013 at 11:23:07PM +0200, Richard Weinberger wrote:
virProcessGetNamespaces() opens files in /proc/XXX/ns/ which will
later be passed to setns().
We have to make sure that the file descriptors in the array are in the correct
order. Otherwise setns() may fail.
What is the scenario / cause of the failure ?
You cannot attach to namespaces in random order.
For example with user namespaces an unprivileged can enter other namespaces.
But to do so you have to enter the user namespace first and then
the other ones.
Ok, that kind of makes sense, ACK to the patch. I'll update the commit
message with this information.
Thanks. :)
FYI: util-linux's nsenter.c says:
/* Careful the order is significant in this array.
*
* The user namespace comes first, so that it is entered
* first. This gives an unprivileged user the potential to
* enter the other namespaces.
*/
{ .nstype = CLONE_NEWUSER, .name = "ns/user", .fd = -1 },
{ .nstype = CLONE_NEWIPC, .name = "ns/ipc", .fd = -1 },
{ .nstype = CLONE_NEWUTS, .name = "ns/uts", .fd = -1 },
{ .nstype = CLONE_NEWNET, .name = "ns/net", .fd = -1 },
{ .nstype = CLONE_NEWPID, .name = "ns/pid", .fd = -1 },
{ .nstype = CLONE_NEWNS, .name = "ns/mnt", .fd = -1 },
{ .nstype = 0, .name = NULL, .fd = -1 }
Same for mnt and pid, if you enter the mnt namespace before pid
your procfs will go nuts.
That shouldn't affect us since we don't need to access procfs at all
during the loop where we call setns().
Yeah, but there are some setns() combination which may still fail.
Some weeks ago I wrote my own ns attach tool that worked also with
user namespaces.
After debugging a few very strange issues there setns() failed all of
the sudden I realized that the setns() order matters.
Thanks,
//richard
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list