[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 6/6] RFC: tools/dm_restrict: Enable QEMU sandboxing
George Dunlap writes ("Re: [PATCH v2 6/6] RFC: tools/dm_restrict: Enable QEMU sandboxing"): > From qemu-depriv.md: > > `elevateprivileges` is currently required to allow `-runas` to work. > Removing this requirement would mean making sure that the uid change > happened before the seccomp2 call, perhaps by changing the uid before > executing QEMU. (But this would then require other changes to create > the QMP socket, VNC socket, and so on). > > Should I C&P this into a comment here? Yes. I think the conclusion I would draw from that comment is not that the uid change should happen before exec'ing qemu, but that the seccomp call in qemu is made too early. But fine. > > In this syntax, what happens with unmentioned abilities ? > > Good question -- the -help doesn't seem to say. Looking at the code > (qemu-seccomp.c:parse_sandbox()) for those who want to follow along at > home), it seems different options have different default values (which > are not mentioned) -- obsolete is default deny, but spawn, > elevateprivileges, and resourcsecontrol are default allow. Erk. I guess we could parse -help output :-/. What about capabilities not known to the qemu source code ? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |