[systemd-devel] systemd-nspawn create container under unprivileged user

[Lennart Poettering]

On Wed, 11.02.15 17:53, Djalal Harouni (tixxdz at opendz.org) wrote:

> On Wed, Feb 11, 2015 at 05:06:56PM +0100, Lennart Poettering wrote:
> > On Wed, 11.02.15 13:53, Djalal Harouni (tixxdz at opendz.org) wrote:
> > 
> > > On Tue, Feb 10, 2015 at 12:52:34PM +0100, Lennart Poettering wrote:
> > > > On Thu, 05.02.15 02:03, Vasiliy Tolstov (v.tolstov at selfip.ru) wrote:
> > > > 
> > > > > Hello!
> > > > > Does it possible to create container as regular user? Oh what capabilities
> > > > > i need to add to create container not using root?
> > > > 
> > > > Invoking containers without privileges is not supported by nspawn, and
> > > > this is unlikely to change, as I fail to see any strong usecase for
> > > > this... 
> > > >
> > > > If somebody can englighten me about the usecase for allowing
> > > > containers to be run by unprivileged users, I'd be willing to change
> > > > my mind though...
> > > A quick argument against it, IOW just wait and see!
> > > 
> > > As unprivileged we don't have CAP_SYS_MODULE set, but inside
> > > unprivileged containers we are root, and a call to cap_get_flag() on
> > > CAP_SYS_MODULE will return CAP_SET! but hey in reality this is not true,
> > > we don't have CAP_SYS_MODULE... this will confuse programs running
> > > inside containers, we'll have to add more code paths for this special
> > > case... and not only CAP_SYS_MODULE, perhaps there are other cases...
> > 
> > Well, but we could drop CAP_SYS_MODULE both before and after setting
> > up the userns, so that the cap is missing fro the PID both inside and
> > outside of it...
> Indeed, yes but still there are other obscure cases, like CAP_SYS_ADMIN,
> even if you have it, you won't be able to mount file systems like btrfs
> and others, only a subset of virtual filesystems support unprivileged
> user mounting... yeh we could drop it too, and it seems that systemd was
> adapted recently to work in this situation, but what about other code ?
> or if you want todo some sort of system replication inside
> container...

Well, some mounting is allowed if you have in CAP_SYS_ADMIN, so we can
pass this out, I figure...

Note that the inability to mount btrfs shouldn't be too limiting,
since we don't expose physical devices in nspawn anyway, and what you
don't have you cannot mount anyway...

Lennart

-- 
Lennart Poettering, Red Hat