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:




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

edk@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.