Thank you for this thourough investigation and for finding the workaround !
I just submitted a patch to the doc based on your email. Cheers, Edouard. conjaroy writes: > In an eariler bug comment [1] I corroborated that nscd was leaking > /etc/passwd information from the host OS into the Guix container, and I > wondered aloud why the container would use the host OS's nscd if there was > a risk of this happening. > > I've looked into how Guix configures its own nscd, and it turns out that by > default it enables lookups only for `hosts` and `services` - not for > `passwd`, `group`, or `netgroup`. Presumably, then, this configuration is > sufficient for nscd to prevent the glibc compatibility issues described in > the manual [3]. > > After adding the following 3 lines in nscd.conf on my foreign distro > (Debian 10) and restarting nscd, my Guix system containers were able to > boot successfully while talking to the daemon: > > enable-cache passwd no > enable-cache group no > enable-cache netgroup no > > So I think the bug here is that the Guix manual page advising the use of > nscd on a foreign distro [3] doesn't elaborate on which types of service > lookups are safe to enable in the daemon. If Guix is used only to build and > run binaries then perhaps it could use nscd for all lookups, but this is > evidently not the case for Guix system containers. > > > Cheers, > > Jason > > > [1] https://www.mail-archive.com/bug-guix@gnu.org/msg19915.html > [2] > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/base.scm?h=version-1.1.0#n1238 > [3] https://guix.gnu.org/manual/en/html_node/Application-Setup.html > > On Mon, Aug 24, 2020 at 11:15 PM conjaroy <conja...@gmail.com> wrote: > >> I've observed this error under similar circumstances: launching a guix >> system container script with network sharing enabled, on a foreign disto >> (Debian 10) with nscd running. >> >> Using `strace -f /gnu/store/...-run-container`, we can observe the >> container's lookup of user accounts via the foreign distro's nscd socket: >> >> [pid 16582] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 11 >> [pid 16582] connect(11, {sa_family=AF_UNIX, >> sun_path="/var/run/nscd/socket"}, 110) = 0 >> [pid 16582] sendto(11, "\2\0\0\0\0\0\0\0\t\0\0\0postgres\0", 21, >> MSG_NOSIGNAL, NULL, 0) = 21 >> [pid 16582] poll([{fd=11, events=POLLIN|POLLERR|POLLHUP}], 1, 5000) = 1 >> ([{fd=11, revents=POLLIN}]) >> [pid 16582] read(11, >> "\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\0\0\0\0\0\0\0\0"..., >> 36) = 36 >> [pid 16582] close(11) = 0 >> >> Since the user ("postgres") is indeed missing in the foreign disto, the >> lookup fails. In this case, disabling nscd on the foreign distro allowed >> the container script to run without error. >> >> Based on comments in https://issues.guix.info/issue/28128, I see that it >> was a deliberate choice to bind-mount the foreign distro's nscd socket >> inside the container (instead of starting a separate containerized nscd >> instance). But I'm having trouble seeing why it's acceptable to leak state >> from the foreign distro's user space into the container. Is there something >> I'm missing? >> >> Cheers, >> >> Jason >>
