[systemd-devel] nspawn: devpts not mounted with PrivateUsers

Olaf the Lost Viking olaf.the.lost.viking at gmail.com
Wed Apr 19 22:14:14 UTC 2017


Dear Lennart & list,


thank you for taking your time to answer (and for systemd :-) )!

(TL;DR -> SOLVED)


On Mittwoch, 19. April 2017 18:37:58 CEST Lennart Poettering wrote:
> > == On the host:
> > $ groupadd -g3777036288 MY_GROUP
> 
> Don't do this. If you register the group like this, nspawn will
> normally abstain from using this group. Use "nss-mymachines" instead
> (consider lobbying your distro to turn it on automatically when
> nspawn/machined are installed) which will make all private UIDs used
> by nspawn (or any other machined registered containers) appear in the
> user database (as shown by getent passwd) without any modification of
> /etc/passwd or any other file therein.

I'm glad that I don't have to do that! It was one of the experiments to get 
things to to work. Letting systemd do that automatically is much, much better!

The nss-mymachines/myhostname/resolve/systemd aren't installed in a Debian 
minbase - you are right! I figured that out, too, and installed them manually. 
But I guess this is fair as I explicitly asked for a _minimal_ installation. 


> > $ echo MY_GROUP:3777036288:65536 >> /etc/subgid
> 
> "subuid" and "subgid" is not used by nspawn. Quite frankly, I am
> pretty sure these files are pretty broken concepts...

That's very relieving to hear - here the same experiments as above were the 
culprit.


> >   systemd-nspawn[6345]: Failed to mount devpts on
> >   /var/lib/machines/MY_CONTAINER/dev/pts (MS_NOSUID|MS_NOEXEC
> >   "newinstance,ptmxmode=0666,mode=620,gid=3777036293"): Invalid
> >   argument
> 
> Because Linux is really really broken, devpts' gid= parameter is
> parsed as signed integer, and then cast to an unsigned one. This
> effectively prohibits using any UIDs > 2^31-1 for containers, if you
> want to use devpts... If you try anyway, you get EINVAL back... In
> other words, pick a lower UID base (or let nspawn pick it for you),
> and it should work.

Wow - how unfortunate. Thank you for pointing that out - even though my naming 
scheme (first byte host, second byte container) goes down the drain now ;).


A short summary for people going through the archive:

I meanwhile deleted all sub?id/passwd/group entries, installed all the systemd 
provided nss packages and activated them in /etc/nsswitch.conf as described in 
the systemd-manual:

passwd:         compat mymachines systemd
group:          compat mymachines systemd
hosts:          files  mymachines resolve [!UNAVAIL=return] dns myhostname

PrivateUsers is commented out in the nspawn config file. machined did choose a 
random UID for a newly started machine:

# ls -ld /var/lib/machines/nsstest1
drwxr-xr-x 1 vu-nsstest1-0 vg-nsstest1-0 154 Apr 19 17:14 /var/lib/machines/
nsstest1

Actually, I wasted some time and even rebooted the whole server to be safe 
because the container user was still named vu-container/vg-container even 
though I thought I deleted all traces... until I found out machined is giving 
out the same names as I did before manually :D


So, in the end, Lennart's solution (install the systemd provided nss libs and 
let PrivateUsers alone) seems to be the best (and working ;-) ) one!


Thanks again for the help!



More information about the systemd-devel mailing list