From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id qKGhFFo2Xl+eRAAA0tVLHw (envelope-from ) for ; Sun, 13 Sep 2020 15:10:18 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id yMn1Dlo2Xl9WOAAAbx9fmQ (envelope-from ) for ; Sun, 13 Sep 2020 15:10:18 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id CAC359401AE for ; Sun, 13 Sep 2020 15:10:17 +0000 (UTC) Received: from localhost ([::1]:60226 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kHTdw-0006s6-QY for larch@yhetil.org; Sun, 13 Sep 2020 11:10:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45408) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kHTdj-0006qD-1G for bug-guix@gnu.org; Sun, 13 Sep 2020 11:10:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:39817) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kHTdi-0002gB-Ll for bug-guix@gnu.org; Sun, 13 Sep 2020 11:10:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kHTdi-0007Eq-GW for bug-guix@gnu.org; Sun, 13 Sep 2020 11:10:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#41575: Container with openssh-service requires sshd user on the host Resent-From: conjaroy Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sun, 13 Sep 2020 15:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41575 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: edk@beaver-labs.com Received: via spool by 41575-submit@debbugs.gnu.org id=B41575.160000976927781 (code B ref 41575); Sun, 13 Sep 2020 15:10:02 +0000 Received: (at 41575) by debbugs.gnu.org; 13 Sep 2020 15:09:29 +0000 Received: from localhost ([127.0.0.1]:51363 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kHTdA-0007E1-Vh for submit@debbugs.gnu.org; Sun, 13 Sep 2020 11:09:29 -0400 Received: from mail-ej1-f44.google.com ([209.85.218.44]:45581) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kHTd6-0007Dl-Br for 41575@debbugs.gnu.org; Sun, 13 Sep 2020 11:09:26 -0400 Received: by mail-ej1-f44.google.com with SMTP id i26so19689991ejb.12 for <41575@debbugs.gnu.org>; Sun, 13 Sep 2020 08:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7uLvrhmMb5bXSuMq25K2mCyAhMblDbh94GTCI+wwy9o=; b=cRyVlIcAcApMn0WTIwWssQ3rtiTWjuMCA/QRBGCvvtl6Ul6iDQclAn9PYNeQFp0OiJ RE48x93uvnyRsW0q2YwHNkeuoE9q/4iQCh4jCkGSB4e9637K24Etap5nR/YrbvcaofB3 xp6KSCQQfsfdQEjQyFO9EKGOVEq9xq8mxZycF1x66wvJXjU0I83An9ZnNftIaO2hAJ+f Q4Su10zmoBqDPW5AsnMPS9hshIcKE4Gbuu5qjFbIaDesJq9mlC6HewX6t+/j+sIscdVW bdR30oWaz591iy5wsDe/gnn+nHGh3t5BTeXCJ++BIJJiTFfIVx5b9g5Zlw6USdni3oA5 kDHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7uLvrhmMb5bXSuMq25K2mCyAhMblDbh94GTCI+wwy9o=; b=RLE9xiX8cX6vCL4sxMxZIom2M04NAL/m3whvfxzHLy42czbR6MHZP0fLFw+Cclr0Qy qS/i3ds4MRrEbskojct4J+ci17BtYTPTdRiuRaxAlF4X51nBRoAsqOGWxvjdiosIwCb4 SSb5L0xqZYqXTAA3fin/XKeQ6hscD8q6d6Vl/mT63nJo1MfzZjCulpOE0JxuaLOfk7PI OWZ3OHbh5t5YoSFUhHmnaF41M/ER6/dBS/8VxidG0naQzBW1HxoiNU0xFpu4tizgp5i2 AyWp3D4s0LagKxIoztQhdPKax1cPzQCPmsbvB32ryLsyIit1uVBr6ufZ7llRzzF4mbJu gohQ== X-Gm-Message-State: AOAM532xAjXGuBH+VjoxA655nDQPS4uVm7tlB/b92uq1dGN4I6ydN/+1 Rd7NLoSrG8ZAoZfPkqNTQli4vqYBVEUF6RJuV+U= X-Google-Smtp-Source: ABdhPJxDBZwB12NVDi+yG4v2jVCvVHB0P2U1fmnD7LkRc1i6Ca97DBayrMhPwvUpJr6upRlDOTUq38G+EWZlZAKWtsM= X-Received: by 2002:a17:906:ce4b:: with SMTP id se11mr10401627ejb.386.1600009758411; Sun, 13 Sep 2020 08:09:18 -0700 (PDT) MIME-Version: 1.0 References: <87imcit0yy.fsf@rdklein.fr> In-Reply-To: <87imcit0yy.fsf@rdklein.fr> From: conjaroy Date: Sun, 13 Sep 2020 11:08:42 -0400 Message-ID: Content-Type: multipart/alternative; boundary="0000000000004990e905af334d10" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -1.0 (-) X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 41575@debbugs.gnu.org Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=gmail.com header.s=20161025 header.b=cRyVlIcA; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Spam-Score: 1.09 X-TUID: eal+xNTGouB8 --0000000000004990e905af334d10 Content-Type: text/plain; charset="UTF-8" My pleasure, Edouard. Thanks for the doc update! Jason On Sun, Sep 13, 2020 at 6:39 AM 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@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 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 > >> > > --0000000000004990e905af334d10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My pleasure, Edouard. Thanks for the doc update!

Jason

On Sun, Sep 13, 2020 at 6:39 AM <edk@beaver-labs.com> wrote:
<= /div>
Thank you for this t= hourough 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 t= here was
> a risk of this happening.
>
> I've looked into how Guix configures its own nscd, and it turns ou= t 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 describe= d 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 t= o
> boot successfully while talking to the daemon:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enable-cache=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 passwd=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 no
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enable-cache=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 group=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0no
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enable-cache=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 netgroup=C2=A0 =C2=A0 =C2=A0 =C2=A0 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 s= ervice
> lookups are safe to enable in the daemon. If Guix is used only to buil= d 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]
> ht= tps://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/base.scm?h=3Dver= sion-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@gmail.com> wrote:
>
>> I've observed this error under similar circumstances: launchin= g 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) =3D 11
>> [pid 16582] connect(11, {sa_family=3DAF_UNIX,
>> sun_path=3D"/var/run/nscd/socket"}, 110) =3D 0
>> [pid 16582] sendto(11, "\2\0\0\0\0\0\0\0\t\0\0\0postgres\0&qu= ot;, 21,
>> MSG_NOSIGNAL, NULL, 0) =3D 21
>> [pid 16582] poll([{fd=3D11, events=3DPOLLIN|POLLERR|POLLHUP}], 1, = 5000) =3D 1
>> ([{fd=3D11, revents=3DPOLLIN}])
>> [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) =3D 36
>> [pid 16582] close(11)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0=3D 0
>>
>> Since the user ("postgres") is indeed missing in the for= eign disto, the
>> lookup fails. In this case, disabling nscd on the foreign distro a= llowed
>> the container script to run without error.
>>
>> Based on comments in https://issues.guix.info/issue/281= 28, I see that it
>> was a deliberate choice to bind-mount the foreign distro's nsc= d socket
>> inside the container (instead of starting a separate containerized= nscd
>> instance). But I'm having trouble seeing why it's acceptab= le to leak state
>> from the foreign distro's user space into the container. Is th= ere something
>> I'm missing?
>>
>> Cheers,
>>
>> Jason
>>

--0000000000004990e905af334d10--