[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