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 <l...@gnu.org> wrote: > Hi, > > e...@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’. >
