On Fri, 09.01.15 01:16, Tom Gundersen (t...@jklm.no) wrote: > On Fri, Jan 9, 2015 at 12:55 AM, Stéphane Graber <stgra...@ubuntu.com> wrote: > > I expect we'll run into some more problems when dealing with units that > > start with their own view of /dev since mknod in a userns isn't allowed > > but I haven't run into one of those yet so it's not very high on my list. > > > > Once that happens, I expect we can solve it either by again just > > ignoring the failure or by catching the failure and falling back to > > doing a bind-mount of the device in question from the parent /dev (which > > works fine in a userns and is what we do today for nested containers > > with LXC). > > Ignoring the failure as in starting services with an empty /dev sounds > like it won't work. Also, just using the parent dev despite explicitly > being asked not to sounds dangerous (most of the time there won't be > much interesting stuff in /dev in a container, but that is not > guaranteed).
Well, I think it's OK to gracefully skip the extra namespacing PrivateDevices=, PrivateTmp= and so on do if we lack the privs for it. I mean, these options are for limiting attack surface to a minimum. But if you run in a CAP_SYS_ADMIN-less or even userns-enabled container, then your attack surfaces is kinda already smaller than what PrivateDevices=, PrivateTmp= and so on would provide, hence we should be OK. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
