GNU bug report logs - #41575
Container with openssh-service requires sshd user on the host

Previous Next

To reply to this bug, email your comments to 41575 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Edouard Klein <edk <at> beaver-labs.com>
To: bug-guix <at> gnu.org
Subject: Container with openssh-service requires sshd user on the host
Date: Thu, 28 May 2020 11:20:25 +0200

Dear guix,

This is a funny one.

Consider this minimal operating system definition:
-----------
(use-modules (gnu))
(use-service-modules ssh)

(operating-system
  (host-name "MinimalSSH")
  (timezone "Europe/Paris")
  (bootloader (bootloader-configuration
               (bootloader grub-bootloader)))
  (file-systems %base-file-systems)
  (services (append (list 
                     (service openssh-service-type
                              (openssh-configuration
                               (port-number 2222))))
                    %base-services)))
-----------

If I try to create a container (with network of course):

guix system container ~/src/gendscraper/minimal_openssh.scm --network

And run the container

sudo /gnu/store/6dvy8acvzkzfba8hjf4nfc3ps2rwns5j-run-container

I get the error I pasted at the end of this email.

If, however, I create a sshd user on the host, it runs without a hitch
and I can talk to the ssh server on localhost:2222

Funny things:
- It will run if I remove the --network (but then I can't connect to the
ssh server, of course)
- It will run if I userdel sshd, until I reboot

The ncsd daemon is running on the host.

My goal with guix containers is to avoid having to make any
configuration on the foreign host (apart from installing guix),
is this normal that the sshd user has to be present for the container
to run the ssh daemon ?

If it is, how can I know in advance which service requires which
configuration on the host ?

Thanks in advance for any help, please do not hesitate to ask for more
information about my config (Arch) if need be.

Cheers,

Edouard.

---------------
sudo /gnu/store/6dvy8acvzkzfba8hjf4nfc3ps2rwns5j-run-container
guile: warning: failed to install locale
system container is running as PID 3934
Run 'sudo guix container exec 3934 /run/current-system/profile/bin/bash --login'
or run 'sudo nsenter -a -t 3934' to get a shell into it.

making '/gnu/store/ml63vj43bv4lrmwdvpm6jqyya24z6zkr-system' the current system...
setting up setuid programs in '/run/setuid-programs'...
populating /etc from /gnu/store/a4d90ypz1xylh97ff2b4ysj33hwnmfva-etc...
Backtrace:
          12 (primitive-load "/gnu/store/6dvy8acvzkzfba8hjf4nfc3ps2r…")
In gnu/build/linux-container.scm:
    297:8 11 (call-with-temporary-directory #<procedure 7f36d0d122d0…>)
   325:16 10 (_ _)
     62:6  9 (call-with-clean-exit _)
In unknown file:
           8 (primitive-load "/gnu/store/ml63vj43bv4lrmwdvpm6jqyya24…")
In ice-9/eval.scm:
    619:8  7 (_ #f)
In unknown file:
           6 (primitive-load "/gnu/store/zdqjch5xknlhp6dvnl6vdrlfnbm…")
In srfi/srfi-1.scm:
    640:9  5 (for-each #<procedure primitive-load (_)> _)
In unknown file:
           4 (primitive-load "/gnu/store/y19c6kipzqigz15v4hvy53x2vaz…")
In gnu/build/activation.scm:
    145:2  3 (activate-users+groups _ _)
In srfi/srfi-1.scm:
    640:9  2 (for-each #<procedure make-home-directory (user)> _)
In gnu/build/activation.scm:
   115:16  1 (make-home-directory #<<user-account> name: "sshd" pass…>)
In unknown file:
           0 (getpw "sshd")

ERROR: In procedure getpw:
In procedure getpw: entry not found

Message #8 received at 41575 <at> debbugs.gnu.org (full text, mbox):

From: conjaroy <conjaroy <at> gmail.com>
To: 41575 <at> debbugs.gnu.org
Subject: Re: Container with openssh-service requires sshd user on the host
Date: Mon, 24 Aug 2020 23:15:04 -0400

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Message #11 received at 41575 <at> debbugs.gnu.org (full text, mbox):

From: conjaroy <conjaroy <at> gmail.com>
To: 41575 <at> debbugs.gnu.org
Cc: edk <at> beaver-labs.com
Subject: Re: Container with openssh-service requires sshd user on the host
Date: Tue, 8 Sep 2020 20:31:47 -0400

[Message part 1 (text/plain, inline)]

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 <at> 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 <conjaroy <at> 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
>

[Message part 2 (text/html, inline)]

Message #14 received at 41575 <at> debbugs.gnu.org (full text, mbox):

From: edk <at> beaver-labs.com
To: guix-patches <at> gnu.org
Cc: 41575 <at> debbugs.gnu.org, conjaroy <conjaroy <at> gmail.com>
Subject: [PATCH] doc: prevent host/container nscd mismatch
Date: Sun, 13 Sep 2020 12:30:49 +0200

doc/guix.texi: (Name Service Switch) add a workaround for bug #41575
---
 doc/guix.texi | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index a6e14ea177..a9472e680e 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -1706,6 +1706,20 @@ this binary incompatibility problem because those @code{libnss_*.so}
 files are loaded in the @command{nscd} process, not in applications
 themselves.
 
+For applications running in containers (@pxref{Invokin guix container}),
+however, @code{nscd} may leak information from the host to the container.
+If there is a configuration mismatch between the two ---e.g., the host
+has no @code{sshd} user while the container needs one--- then it may be
+worthwhile to limit which kind of information the host's @code{nscd}
+daemon may give to the container by adding the following to
+@code{/etc/nscd.conf}.
+
+@example
+        enable-cache            passwd          no
+        enable-cache            group           no
+        enable-cache            netgroup        no
+@end example
+
 @subsection X11 Fonts
 
 @cindex fonts
@@ -27582,7 +27596,7 @@ that should be preferably killed.
 
 @item @code{avoid-regexp} (default: @code{#f})
 A regular expression (as a string) to match the names of the processes
-that should @emph{not} be killed.
+that should @emph{not} be kcoilled.
 
 @item @code{memory-report-interval} (default: @code{0})
 The interval in seconds at which a memory report is printed.  It is
-- 
2.28.0

Message #17 received at 41575 <at> debbugs.gnu.org (full text, mbox):

From: edk <at> beaver-labs.com
To: conjaroy <conjaroy <at> gmail.com>
Cc: 41575 <at> debbugs.gnu.org
Subject: Re: Container with openssh-service requires sshd user on the host
Date: Sun, 13 Sep 2020 12:39:17 +0200

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 <at> 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 <conjaroy <at> 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
>>

Message #20 received at 41575 <at> debbugs.gnu.org (full text, mbox):

From: conjaroy <conjaroy <at> gmail.com>
To: edk <at> beaver-labs.com
Cc: 41575 <at> debbugs.gnu.org
Subject: Re: Container with openssh-service requires sshd user on the host
Date: Sun, 13 Sep 2020 11:08:42 -0400

[Message part 1 (text/plain, inline)]

My pleasure, Edouard. Thanks for the doc update!

Jason

On Sun, Sep 13, 2020 at 6:39 AM <edk <at> beaver-labs.com> wrote:

> 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 <at> 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 <conjaroy <at> 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
> >>
>
>

[Message part 2 (text/html, inline)]

Message #23 received at 41575 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: edk <at> beaver-labs.com
Cc: 43371 <at> debbugs.gnu.org, conjaroy <conjaroy <at> gmail.com>, 41575 <at> debbugs.gnu.org
Subject: Re: [bug#43371] [PATCH] doc: prevent host/container nscd mismatch
Date: Sun, 13 Sep 2020 23:05:09 +0200

Hi,

edk <at> beaver-labs.com skribis:

> doc/guix.texi: (Name Service Switch) add a workaround for bug #41575
> ---
>  doc/guix.texi | 16 +++++++++++++++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/doc/guix.texi b/doc/guix.texi
> index a6e14ea177..a9472e680e 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -1706,6 +1706,20 @@ this binary incompatibility problem because those @code{libnss_*.so}
>  files are loaded in the @command{nscd} process, not in applications
>  themselves.
>  
> +For applications running in containers (@pxref{Invokin guix container}),
> +however, @code{nscd} may leak information from the host to the container.
> +If there is a configuration mismatch between the two ---e.g., the host
> +has no @code{sshd} user while the container needs one--- then it may be

I find the example is hard to understand.  How about: “applications in
the container could end up looking users in the host”?

> +worthwhile to limit which kind of information the host's @code{nscd}
> +daemon may give to the container by adding the following to
> +@code{/etc/nscd.conf}.
> +
> +@example
> +        enable-cache            passwd          no
> +        enable-cache            group           no
> +        enable-cache            netgroup        no
> +@end example

Actually, perhaps the better fix is to never use the host’s nscd?  We
could change ‘containerized-operating-system’ accordingly.

That would allow guest OSes to work correctly regardless of the host’s
nscd config, which seems like an improvement.

Thoughts?

Ludo’.

Message #26 received at 41575 <at> debbugs.gnu.org (full text, mbox):

From: conjaroy <conjaroy <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 43371 <at> debbugs.gnu.org, edk <at> beaver-labs.com, 41575 <at> debbugs.gnu.org
Subject: Re: [bug#43371] [PATCH] doc: prevent host/container nscd mismatch
Date: Sun, 13 Sep 2020 21:05:58 -0400

[Message part 1 (text/plain, inline)]

Hello Ludo',

A separate nscd per container also seems like a reasonable option. However,
for the sake of machines hosting many long-lived containers, perhaps we
should consider reducing the cache size: currently it's 32MB for each name
service type, with an expiration of 12-24 hours:

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/base.scm?id=1042d269a723360a02b19a2baafef1e24a3bfc73#n1115

Cheers,

Jason

On Sun, Sep 13, 2020 at 5:05 PM Ludovic Courtès <ludo <at> gnu.org> wrote:

> Hi,
>
> edk <at> beaver-labs.com skribis:
>
> > doc/guix.texi: (Name Service Switch) add a workaround for bug #41575
> > ---
> >  doc/guix.texi | 16 +++++++++++++++-
> >  1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/guix.texi b/doc/guix.texi
> > index a6e14ea177..a9472e680e 100644
> > --- a/doc/guix.texi
> > +++ b/doc/guix.texi
> > @@ -1706,6 +1706,20 @@ this binary incompatibility problem because those
> @code{libnss_*.so}
> >  files are loaded in the @command{nscd} process, not in applications
> >  themselves.
> >
> > +For applications running in containers (@pxref{Invokin guix container}),
> > +however, @code{nscd} may leak information from the host to the
> container.
> > +If there is a configuration mismatch between the two ---e.g., the host
> > +has no @code{sshd} user while the container needs one--- then it may be
>
> I find the example is hard to understand.  How about: “applications in
> the container could end up looking users in the host”?
>
> > +worthwhile to limit which kind of information the host's @code{nscd}
> > +daemon may give to the container by adding the following to
> > +@code{/etc/nscd.conf}.
> > +
> > +@example
> > +        enable-cache            passwd          no
> > +        enable-cache            group           no
> > +        enable-cache            netgroup        no
> > +@end example
>
> Actually, perhaps the better fix is to never use the host’s nscd?  We
> could change ‘containerized-operating-system’ accordingly.
>
> That would allow guest OSes to work correctly regardless of the host’s
> nscd config, which seems like an improvement.
>
> Thoughts?
>
> Ludo’.
>

[Message part 2 (text/html, inline)]

Message #29 received at 41575 <at> debbugs.gnu.org (full text, mbox):

From: Edouard Klein <edou <at> rdklein.fr>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 43371 <at> debbugs.gnu.org, conjaroy <conjaroy <at> gmail.com>, 41575 <at> debbugs.gnu.org
Subject: Re: [bug#43371] [PATCH] doc: prevent host/container nscd mismatch
Date: Mon, 14 Sep 2020 09:24:32 +0200

Hi !

Ludovic Courtès writes:

> Hi,
>
> edk <at> beaver-labs.com skribis:
>
>> doc/guix.texi: (Name Service Switch) add a workaround for bug #41575
>> ---
>>  doc/guix.texi | 16 +++++++++++++++-
>>  1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/doc/guix.texi b/doc/guix.texi
>> index a6e14ea177..a9472e680e 100644
>> --- a/doc/guix.texi
>> +++ b/doc/guix.texi
>> @@ -1706,6 +1706,20 @@ this binary incompatibility problem because those @code{libnss_*.so}
>>  files are loaded in the @command{nscd} process, not in applications
>>  themselves.
>>  
>> +For applications running in containers (@pxref{Invokin guix container}),
>> +however, @code{nscd} may leak information from the host to the container.
>> +If there is a configuration mismatch between the two ---e.g., the host
>> +has no @code{sshd} user while the container needs one--- then it may be
>
> I find the example is hard to understand.  How about: “applications in
> the container could end up looking users in the host”?
>
>> +worthwhile to limit which kind of information the host's @code{nscd}
>> +daemon may give to the container by adding the following to
>> +@code{/etc/nscd.conf}.
>> +
>> +@example
>> +        enable-cache            passwd          no
>> +        enable-cache            group           no
>> +        enable-cache            netgroup        no
>> +@end example
>
> Actually, perhaps the better fix is to never use the host’s nscd?  We
> could change ‘containerized-operating-system’ accordingly.
>

I think this would be best, but I did not know where to make this
change, so I just edited the doc instead. I don't know if containers
need the host's nscd to avoid the libc issues mentionned in the doc, but
if they dont, then prevening them from accessing the host's nscd seems
logical and would solve the problem. And we wouldn't need to amend the
doc at all.

> That would allow guest OSes to work correctly regardless of the host’s
> nscd config, which seems like an improvement.
>
> Thoughts?
>
> Ludo’.

Message #32 received at 41575 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: conjaroy <conjaroy <at> gmail.com>
Cc: 43371 <at> debbugs.gnu.org, edk <at> beaver-labs.com, 41575 <at> debbugs.gnu.org
Subject: Re: [bug#43371] [PATCH] doc: prevent host/container nscd mismatch
Date: Mon, 14 Sep 2020 09:26:47 +0200

Hi,

conjaroy <conjaroy <at> gmail.com> skribis:

> A separate nscd per container also seems like a reasonable option. However,
> for the sake of machines hosting many long-lived containers, perhaps we
> should consider reducing the cache size: currently it's 32MB for each name
> service type, with an expiration of 12-24 hours:
>
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/base.scm?id=1042d269a723360a02b19a2baafef1e24a3bfc73#n1115

Good point.

In that case, we can have ‘containerized-operating-system’ provide its
own NSS configuration with a reduced cache size (or without cache since
there’s caching happening on the host for host name lookups, for
instance).

WDYT?  Would you like to give it a try?

Thanks,
Ludo’.

Message #35 received at 41575 <at> debbugs.gnu.org (full text, mbox):

From: conjaroy <conjaroy <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 43371 <at> debbugs.gnu.org, edk <at> beaver-labs.com, 41575 <at> debbugs.gnu.org
Subject: Re: bug#41575: [bug#43371] [PATCH] doc: prevent host/container nscd
 mismatch
Date: Mon, 14 Sep 2020 18:53:30 -0400

[Message part 1 (text/plain, inline)]

Sure, I'm happy to take a stab at this.

Jason

On Mon, Sep 14, 2020 at 3:28 AM Ludovic Courtès <ludo <at> gnu.org> wrote:

> In that case, we can have ‘containerized-operating-system’ provide its
> own NSS configuration with a reduced cache size (or without cache since
> there’s caching happening on the host for host name lookups, for
> instance).
>
> WDYT?  Would you like to give it a try?
>
> Thanks,
> Ludo’.
>
>
>
>

[Message part 2 (text/html, inline)]

Message #38 received at 41575 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Edouard Klein <edou <at> rdklein.fr>
Cc: 41575 <at> debbugs.gnu.org, 43371-done <at> debbugs.gnu.org,
 conjaroy <conjaroy <at> gmail.com>
Subject: Re: [bug#43371] [PATCH] doc: prevent host/container nscd mismatch
Date: Mon, 05 Oct 2020 10:36:05 +0200

Hi,

Edouard Klein <edou <at> rdklein.fr> skribis:

>> Actually, perhaps the better fix is to never use the host’s nscd?  We
>> could change ‘containerized-operating-system’ accordingly.
>>
>
> I think this would be best, but I did not know where to make this
> change, so I just edited the doc instead. I don't know if containers
> need the host's nscd to avoid the libc issues mentionned in the doc, but
> if they dont, then prevening them from accessing the host's nscd seems
> logical and would solve the problem. And we wouldn't need to amend the
> doc at all.

This has now been done by Jason in
5627bfe45ce46f498979b4ad2deab1fdfed22b6c.

Closing!

Ludo’.

Message #41 received at 41575 <at> debbugs.gnu.org (full text, mbox):

From: Edouard Klein <edou <at> rdklein.fr>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 41575 <at> debbugs.gnu.org, 43371-done <at> debbugs.gnu.org,
 conjaroy <conjaroy <at> gmail.com>
Subject: Re: [bug#43371] [PATCH] doc: prevent host/container nscd mismatch
Date: Mon, 05 Oct 2020 19:01:58 +0200

Thanks to you both :)


Ludovic Courtès writes:

> Hi,
>
> Edouard Klein <edou <at> rdklein.fr> skribis:
>
>>> Actually, perhaps the better fix is to never use the host’s nscd?  We
>>> could change ‘containerized-operating-system’ accordingly.
>>>
>>
>> I think this would be best, but I did not know where to make this
>> change, so I just edited the doc instead. I don't know if containers
>> need the host's nscd to avoid the libc issues mentionned in the doc, but
>> if they dont, then prevening them from accessing the host's nscd seems
>> logical and would solve the problem. And we wouldn't need to amend the
>> doc at all.
>
> This has now been done by Jason in
> 5627bfe45ce46f498979b4ad2deab1fdfed22b6c.
>
> Closing!
>
> Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.