Received: (at 41575) by debbugs.gnu.org; 13 Sep 2020 15:09:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 13 11:09:29 2020
Received: from localhost ([127.0.0.1]:51363 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1kHTdA-0007E1-Vh
for submit <at> 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 <conjaroy@HIDDEN>) id 1kHTd6-0007Dl-Br
for 41575 <at> 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 <at> 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: <CABWzUjWkKJkAhJi8MMC1SiSZBPjZBBMgbRk7DavR9QQXhhfRDA@HIDDEN>
<CABWzUjV9EXVNrdi86+LUHSUb6Nka87ZPPtGtE52tbW8XhnzRvg@HIDDEN>
<87imcit0yy.fsf@HIDDEN>
In-Reply-To: <87imcit0yy.fsf@HIDDEN>
From: conjaroy <conjaroy@HIDDEN>
Date: Sun, 13 Sep 2020 11:08:42 -0400
Message-ID: <CABWzUjWOZ1rypK2w8Pu8RHsBp6cM+QNhjzKpDGJ=fDajSfUO1g@HIDDEN>
Subject: Re: Container with openssh-service requires sshd user on the host
To: edk@HIDDEN
Content-Type: multipart/alternative; boundary="0000000000004990e905af334d10"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 41575
Cc: 41575 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--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 <edk@HIDDEN> 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@HIDDEN/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@HIDDEN> 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
<div dir=3D"ltr"><div>My pleasure, Edouard. Thanks for the doc update!</div=
><div><br></div><div>Jason<br></div></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Sun, Sep 13, 2020 at 6:39 AM <<a =
href=3D"mailto:edk@HIDDEN">edk@HIDDEN</a>> wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">Thank you for this t=
hourough investigation and for finding the<br>
workaround !<br>
<br>
I just submitted a patch to the doc based on your email.<br>
<br>
Cheers,<br>
<br>
Edouard.<br>
conjaroy writes:<br>
<br>
> In an eariler bug comment [1] I corroborated that nscd was leaking<br>
> /etc/passwd information from the host OS into the Guix container, and =
I<br>
> wondered aloud why the container would use the host OS's nscd if t=
here was<br>
> a risk of this happening.<br>
><br>
> I've looked into how Guix configures its own nscd, and it turns ou=
t that by<br>
> default it enables lookups only for `hosts` and `services` - not for<b=
r>
> `passwd`, `group`, or `netgroup`. Presumably, then, this configuration=
is<br>
> sufficient for nscd to prevent the glibc compatibility issues describe=
d in<br>
> the manual [3].<br>
><br>
> After adding the following 3 lines in nscd.conf on my foreign distro<b=
r>
> (Debian 10) and restarting nscd, my Guix system containers were able t=
o<br>
> boot successfully while talking to the daemon:<br>
><br>
>=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<br>
>=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<br>
>=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<br>
><br>
> So I think the bug here is that the Guix manual page advising the use =
of<br>
> nscd on a foreign distro [3] doesn't elaborate on which types of s=
ervice<br>
> lookups are safe to enable in the daemon. If Guix is used only to buil=
d and<br>
> run binaries then perhaps it could use nscd for all lookups, but this =
is<br>
> evidently not the case for Guix system containers.<br>
><br>
><br>
> Cheers,<br>
><br>
> Jason<br>
><br>
><br>
> [1] <a href=3D"https://www.mail-archive.com/bug-guix@HIDDEN/msg19915.=
html" rel=3D"noreferrer" target=3D"_blank">https://www.mail-archive.com/bug=
-guix@HIDDEN/msg19915.html</a><br>
> [2]<br>
> <a href=3D"https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/service=
s/base.scm?h=3Dversion-1.1.0#n1238" rel=3D"noreferrer" target=3D"_blank">ht=
tps://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/base.scm?h=3Dver=
sion-1.1.0#n1238</a><br>
> [3] <a href=3D"https://guix.gnu.org/manual/en/html_node/Application-Se=
tup.html" rel=3D"noreferrer" target=3D"_blank">https://guix.gnu.org/manual/=
en/html_node/Application-Setup.html</a><br>
><br>
> On Mon, Aug 24, 2020 at 11:15 PM conjaroy <<a href=3D"mailto:conjar=
oy@HIDDEN" target=3D"_blank">conjaroy@HIDDEN</a>> wrote:<br>
><br>
>> I've observed this error under similar circumstances: launchin=
g a guix<br>
>> system container script with network sharing enabled, on a foreign=
disto<br>
>> (Debian 10) with nscd running.<br>
>><br>
>> Using `strace -f /gnu/store/...-run-container`, we can observe the=
<br>
>> container's lookup of user accounts via the foreign distro'=
;s nscd socket:<br>
>><br>
>> [pid 16582] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK=
, 0) =3D 11<br>
>> [pid 16582] connect(11, {sa_family=3DAF_UNIX,<br>
>> sun_path=3D"/var/run/nscd/socket"}, 110) =3D 0<br>
>> [pid 16582] sendto(11, "\2\0\0\0\0\0\0\0\t\0\0\0postgres\0&qu=
ot;, 21,<br>
>> MSG_NOSIGNAL, NULL, 0) =3D 21<br>
>> [pid 16582] poll([{fd=3D11, events=3DPOLLIN|POLLERR|POLLHUP}], 1, =
5000) =3D 1<br>
>> ([{fd=3D11, revents=3DPOLLIN}])<br>
>> [pid 16582] read(11,<br>
>> "\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"...,<br>
>> 36) =3D 36<br>
>> [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<br>
>><br>
>> Since the user ("postgres") is indeed missing in the for=
eign disto, the<br>
>> lookup fails. In this case, disabling nscd on the foreign distro a=
llowed<br>
>> the container script to run without error.<br>
>><br>
>> Based on comments in <a href=3D"https://issues.guix.info/issue/281=
28" rel=3D"noreferrer" target=3D"_blank">https://issues.guix.info/issue/281=
28</a>, I see that it<br>
>> was a deliberate choice to bind-mount the foreign distro's nsc=
d socket<br>
>> inside the container (instead of starting a separate containerized=
nscd<br>
>> instance). But I'm having trouble seeing why it's acceptab=
le to leak state<br>
>> from the foreign distro's user space into the container. Is th=
ere something<br>
>> I'm missing?<br>
>><br>
>> Cheers,<br>
>><br>
>> Jason<br>
>><br>
<br>
</blockquote></div>
--0000000000004990e905af334d10--
bug-guix@HIDDEN:bug#41575; Package guix.
Full text available.
Received: (at 41575) by debbugs.gnu.org; 13 Sep 2020 10:39:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 13 06:39:36 2020
Received: from localhost ([127.0.0.1]:49559 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1kHPQ0-0008ES-6k
for submit <at> debbugs.gnu.org; Sun, 13 Sep 2020 06:39:36 -0400
Received: from sender4-op-o11.zoho.com ([136.143.188.11]:17128)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <edk@HIDDEN>) id 1kHPPv-0008EH-E7
for 41575 <at> debbugs.gnu.org; Sun, 13 Sep 2020 06:39:35 -0400
ARC-Seal: i=1; a=rsa-sha256; t=1599993569; cv=none;
d=zohomail.com; s=zohoarc;
b=FNcejl909SqHfhq2GpzxaeofeBLPuWlcsBmPUB+ymEjrbxhdjDBV/KwQwW+ZLLW8Wo+D0NWFuFF7pN7OLg7UMzlZTSBwXO6S+IS5sp/edReceJdMR5djmuMkm6jkTo1i9E4KIMY74yhzB/HlSj5DAFlK77GvtYJwBZA/jekcfWg=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com;
s=zohoarc; t=1599993569;
h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To;
bh=/QI4pJZwIizdjRsb59+EnAzUxKnTdbjSbcyDSox4jUM=;
b=SyrjJU20N0opKNIO2GGVqRnLaXm8iArNEYPavWstMn/NIXNHPKmgPtQW0cMEAmA/h6O1NpyK29JclAULTeG1qtpOXC4Ny8m7pUcz2UIw+UFI9bm7SS4TkXxcbb7OO+CfcnNl1vRYXKs3eucL9QkqpsNGNlshidE19u62R/JBhK0=
ARC-Authentication-Results: i=1; mx.zohomail.com;
dkim=pass header.i=beaver-labs.com;
spf=pass smtp.mailfrom=edk@HIDDEN;
dmarc=pass header.from=<edk@HIDDEN> header.from=<edk@HIDDEN>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1599993569;
s=zoho; d=beaver-labs.com; i=edk@HIDDEN;
h=References:From:To:Cc:Subject:In-reply-to:Message-ID:Date:MIME-Version:Content-Type;
bh=/QI4pJZwIizdjRsb59+EnAzUxKnTdbjSbcyDSox4jUM=;
b=Xc/wZ2Yv030NrEfJaxbisHoEJuLMq1zcMjKxQv+lTNgFKWPapEKF5EjwJrajQg06
o9D2yHQNj7A578nbktp4u/NIMLUr3GKL6LS33wvMS9iWp6l2cY/v8b6XzMsKtdjecXd
YHOFDOmvSGbKwfi099zEEy/RDeeIV6DLdL4caG5c=
Received: from Rasoir (lfbn-idf3-1-1319-142.w92-170.abo.wanadoo.fr
[92.170.248.142]) by mx.zohomail.com
with SMTPS id 1599993567968848.656711111787;
Sun, 13 Sep 2020 03:39:27 -0700 (PDT)
References: <CABWzUjWkKJkAhJi8MMC1SiSZBPjZBBMgbRk7DavR9QQXhhfRDA@HIDDEN>
<CABWzUjV9EXVNrdi86+LUHSUb6Nka87ZPPtGtE52tbW8XhnzRvg@HIDDEN>
User-agent: mu4e 1.4.4; emacs 27.1
From: edk@HIDDEN
To: conjaroy <conjaroy@HIDDEN>
Subject: Re: Container with openssh-service requires sshd user on the host
In-reply-to: <CABWzUjV9EXVNrdi86+LUHSUb6Nka87ZPPtGtE52tbW8XhnzRvg@HIDDEN>
Message-ID: <87imcit0yy.fsf@HIDDEN>
Date: Sun, 13 Sep 2020 12:39:17 +0200
MIME-Version: 1.0
Content-Type: text/plain
X-ZohoMailClient: External
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 41575
Cc: 41575 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
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@HIDDEN/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@HIDDEN> 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
>>
bug-guix@HIDDEN:bug#41575; Package guix.
Full text available.
Received: (at 41575) by debbugs.gnu.org; 13 Sep 2020 10:31:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 13 06:31:18 2020
Received: from localhost ([127.0.0.1]:49548 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1kHPHx-00081V-PV
for submit <at> debbugs.gnu.org; Sun, 13 Sep 2020 06:31:18 -0400
Received: from sender4-op-o11.zoho.com ([136.143.188.11]:17109)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <edk@HIDDEN>) id 1kHPHw-00081F-Gh
for 41575 <at> debbugs.gnu.org; Sun, 13 Sep 2020 06:31:16 -0400
ARC-Seal: i=1; a=rsa-sha256; t=1599993068; cv=none;
d=zohomail.com; s=zohoarc;
b=NHP5KAbCst7ACD6Adr4aI6yNf9v2xtqTGzjOBZjVAB8w5RKlR2d/q+5pW+EagvPoHUIype3iy9CvPNr8qzX6YENz9H+b/dg/aNFaSLVcupA8C5U/8MGjFkE7W+Hc2evWV+Uxd4ae/72fQXygRNPmQ6J5jZBP38ZMQvKyIbZz2s0=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com;
s=zohoarc;
t=1599993068; h=Content-Type:Cc:Date:From:MIME-Version:Message-ID:Subject:To;
bh=9/Eymdti+Bs5n1qz3AhHhnUk5I1CZZVyiiwiUfvPYdI=;
b=n3At5lRyiNmdYW7RpJjhAoD45WDL0cPjswopzAorpMmrk5uRC875jQtufJ88/6IjJDpQ6ZntAolYbeJJw0IFU09FzkZBwoAxUFyBF2NMFoEc8FFm5rtLDuX3Yx0g8rrPoJPyheRHs29wE3a41Hz8nItW3Yh/o80/ag47WHdyGHc=
ARC-Authentication-Results: i=1; mx.zohomail.com;
dkim=pass header.i=beaver-labs.com;
spf=pass smtp.mailfrom=edk@HIDDEN;
dmarc=pass header.from=<edk@HIDDEN> header.from=<edk@HIDDEN>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1599993068;
s=zoho; d=beaver-labs.com; i=edk@HIDDEN;
h=From:To:Cc:Cc:Subject:Message-ID:Date:MIME-Version:Content-Type;
bh=9/Eymdti+Bs5n1qz3AhHhnUk5I1CZZVyiiwiUfvPYdI=;
b=OKneUkC/5OAMviHla2XfAPT3PsMkkDUth//fE//6cq21h/QlrKT0PBLC5hhmhDsi
s0hagBXjCn+PeZ+/cOdKw+DGpCJ+3Ip3imclowtpnjM6xqyOkuI9vj3CRNGBD5A7anN
okuNJkkgl4uJUPxG5YrVS2LjcB2zVBBCDPZcnWWI=
Received: from Rasoir (lfbn-idf3-1-1319-142.w92-170.abo.wanadoo.fr
[92.170.248.142]) by mx.zohomail.com
with SMTPS id 159999306668558.51591308873799;
Sun, 13 Sep 2020 03:31:06 -0700 (PDT)
User-agent: mu4e 1.4.4; emacs 27.1
From: edk@HIDDEN
To: guix-patches@HIDDEN
Subject: [PATCH] doc: prevent host/container nscd mismatch
Message-ID: <87lfhet1d2.fsf@HIDDEN>
Date: Sun, 13 Sep 2020 12:30:49 +0200
MIME-Version: 1.0
Content-Type: text/plain
X-ZohoMailClient: External
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 41575
Cc: 41575 <at> debbugs.gnu.org, conjaroy <conjaroy@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
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
bug-guix@HIDDEN:bug#41575; Package guix.
Full text available.
Received: (at 41575) by debbugs.gnu.org; 9 Sep 2020 00:32:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 08 20:32:31 2020
Received: from localhost ([127.0.0.1]:56764 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1kFo2J-00008m-75
for submit <at> debbugs.gnu.org; Tue, 08 Sep 2020 20:32:31 -0400
Received: from mail-ej1-f53.google.com ([209.85.218.53]:38988)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <conjaroy@HIDDEN>) id 1kFo2H-00008Z-Er
for 41575 <at> debbugs.gnu.org; Tue, 08 Sep 2020 20:32:30 -0400
Received: by mail-ej1-f53.google.com with SMTP id p9so981362ejf.6
for <41575 <at> debbugs.gnu.org>; Tue, 08 Sep 2020 17:32:29 -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=KlEcsT+k2b3eyyjEC0INa68pgG2ZNXQrd2N6iF8kbYw=;
b=oruAc7ZAKffd64SI4vzHpn2xeSayqndR+NqzHaovk0kHufWRdhYHasp2s433emGyKQ
yq8+I0btoM5VXsoF+Cv1Sa5a/r8O0hVIKxDwf1CX71JPhuj14k/C3qfO4yG3GMdKa2dA
KhvyI1BkHMFvhIvckJXl0OjtgNZu2S48+job4dUJJ7nEBSYJe+/t3TlolDCpGWYkMsD4
y9OeU8q0wX/ot9L9ECKUvS40S2q+3hBpZTP6NHHQalku0+bEkog49T6NAuVjRoFHMJs7
rqNxYnupiMbGsk2AwHqF68paLBxp4NPlzc0OY5meTGyNGPWZ/OWkX1yi30zMEvCzfxp2
tsXQ==
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=KlEcsT+k2b3eyyjEC0INa68pgG2ZNXQrd2N6iF8kbYw=;
b=QijBaekWMlwwWlq9Q9FhHlPDFWwnrDKPRmDuxCMhJPKnlJMxdURzujyjXSDkJvGMzh
3dac90JYhO0ust+JZV5drdn372sx4oDvNriSchgFOg8YcNA1H3/vJiCOvPbKEkkmm12Y
ViwFyX3PoYOQ885wUDoe+mCT7u6qgz2u/KhqGnTZ1AQ9VW4mLFSwekwUJXg7RK8lps55
t3B5XvkrfVaeh17ptcyB1LlQVpQ0tDQqTfVMGaStbuRDhNEATAjvzVPlOljHI1+teREk
1VmR49BTDaWLKLoKWwijLWqKa69NEpnTp8kOaGX21Y0pksGR3m2VmZ9ucbEU0e5I3fz0
5AKQ==
X-Gm-Message-State: AOAM533g4A9NKJDEn5omNq3UBEVMkRd46rAUH/oqObLfi40R7tNFRs/U
I3D9nc+1IZ1blzdQvmRMwnmjaIn4OSQJf1vxWHcQzEeluTI=
X-Google-Smtp-Source: ABdhPJzWPkK7DbVIJslSwGc3sJQvI1ekgfcYeGE4xLYmVTmYd/SLX9IqmTKl9xSlfVmCFqdEGq+vFbPaEOFuVD0ahco=
X-Received: by 2002:a17:906:ce4b:: with SMTP id
se11mr1063169ejb.386.1599611543159;
Tue, 08 Sep 2020 17:32:23 -0700 (PDT)
MIME-Version: 1.0
References: <CABWzUjWkKJkAhJi8MMC1SiSZBPjZBBMgbRk7DavR9QQXhhfRDA@HIDDEN>
In-Reply-To: <CABWzUjWkKJkAhJi8MMC1SiSZBPjZBBMgbRk7DavR9QQXhhfRDA@HIDDEN>
From: conjaroy <conjaroy@HIDDEN>
Date: Tue, 8 Sep 2020 20:31:47 -0400
Message-ID: <CABWzUjV9EXVNrdi86+LUHSUb6Nka87ZPPtGtE52tbW8XhnzRvg@HIDDEN>
Subject: Re: Container with openssh-service requires sshd user on the host
To: 41575 <at> debbugs.gnu.org
Content-Type: multipart/alternative; boundary="000000000000cf093a05aed695b2"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 41575
Cc: edk@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--000000000000cf093a05aed695b2
Content-Type: text/plain; charset="UTF-8"
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@HIDDEN/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@HIDDEN> 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
>
--000000000000cf093a05aed695b2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>In an eariler bug comment [1] I corroborated that nsc=
d was leaking /etc/passwd information from the host OS into the Guix contai=
ner, and I wondered aloud why the container would use the host OS's nsc=
d if there was a risk of this happening.</div><div><br></div><div>I've =
looked into how Guix configures its own nscd, and it turns out that by defa=
ult 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].<br></div><div><br></div><div>After adding the following 3 lines in nsc=
d.conf on my foreign distro (Debian 10) and restarting nscd, my Guix system=
containers were able to boot successfully while talking to the daemon:</di=
v><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 enable-cache =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0passwd =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0no<=
/div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 enable-cache =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0group =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 no</div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 enable-cache =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0netgroup =C2=A0 =C2=A0 =C2=A0 =C2=A0no<br></div><div><br></div><div>S=
o I think the bug here is that the Guix manual page advising the use of nsc=
d on a foreign distro [3] doesn't elaborate on which types of service l=
ookups 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 ev=
idently not the case for Guix system containers.<br></div><div><br></div><d=
iv><br></div><div>Cheers,</div><div><br></div><div>Jason<br></div><div><br>=
</div><div><br></div><div>[1] <a href=3D"https://www.mail-archive.com/bug-g=
uix@HIDDEN/msg19915.html">https://www.mail-archive.com/bug-guix@HIDDEN/ms=
g19915.html</a></div><div>[2] <a href=3D"https://git.savannah.gnu.org/cgit/=
guix.git/tree/gnu/services/base.scm?h=3Dversion-1.1.0#n1238">https://git.sa=
vannah.gnu.org/cgit/guix.git/tree/gnu/services/base.scm?h=3Dversion-1.1.0#n=
1238</a></div><div>[3] <a href=3D"https://guix.gnu.org/manual/en/html_node/=
Application-Setup.html">https://guix.gnu.org/manual/en/html_node/Applicatio=
n-Setup.html</a></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
class=3D"gmail_attr">On Mon, Aug 24, 2020 at 11:15 PM conjaroy <<a href=
=3D"mailto:conjaroy@HIDDEN">conjaroy@HIDDEN</a>> wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>I=
9;ve observed this error under similar circumstances: launching a <span>gui=
x system container script with network sharing enabled, on a foreign disto =
(Debian 10) with nscd running.</span></div><div><br></div><div>Using `strac=
e -f /gnu/store/...-run-container`, we can observe the container's look=
up of user accounts via the foreign distro's nscd socket:<br></div><div=
><br></div><div>[pid 16582] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_N=
ONBLOCK, 0) =3D 11<br>[pid 16582] connect(11, {sa_family=3DAF_UNIX, sun_pat=
h=3D"/var/run/nscd/socket"}, 110) =3D 0<br>[pid 16582] sendto(11,=
"\2\0\0\0\0\0\0\0\t\0\0\0postgres\0", 21, MSG_NOSIGNAL, NULL, 0)=
=3D 21<br>[pid 16582] poll([{fd=3D11, events=3DPOLLIN|POLLERR|POLLHUP}], 1=
, 5000) =3D 1 ([{fd=3D11, revents=3DPOLLIN}])<br>[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<br>[pid 16582] close(11) =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0</div><div><br></div><div><d=
iv>Since the user ("postgres") is indeed missing in the foreign d=
isto, the lookup fails. In this case, disabling nscd on the foreign distro =
allowed the container script to run without error. <br></div><div><br></div=
><div>Based on comments in <a href=3D"https://issues.guix.info/issue/28128"=
target=3D"_blank">https://issues.guix.info/issue/28128</a>, 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 ins=
tance). But I'm having trouble seeing why it's acceptable to leak s=
tate from the foreign distro's user space into the container. Is there =
something I'm missing?</div><div><br></div><div>Cheers,</div><div><br><=
/div><div>Jason<br></div></div><div><span><span></span></span></div></div>
</blockquote></div>
--000000000000cf093a05aed695b2--
bug-guix@HIDDEN:bug#41575; Package guix.
Full text available.
Received: (at 41575) by debbugs.gnu.org; 25 Aug 2020 05:08:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 25 01:08:53 2020
Received: from localhost ([127.0.0.1]:59955 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1kARCW-0001Sx-0g
for submit <at> debbugs.gnu.org; Tue, 25 Aug 2020 01:08:53 -0400
Received: from mail-ed1-f45.google.com ([209.85.208.45]:37378)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <conjaroy@HIDDEN>) id 1kAPR4-0006zV-FR
for 41575 <at> debbugs.gnu.org; Mon, 24 Aug 2020 23:15:49 -0400
Received: by mail-ed1-f45.google.com with SMTP id i26so9923279edv.4
for <41575 <at> debbugs.gnu.org>; Mon, 24 Aug 2020 20:15:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=+e7/nfNGNU5f3z/A9sAKRiDQbC0lvkhqC7HGvdscGQ8=;
b=o9Zq/cCR9V39Tytx2dM/sezY4eBt+2VGnzEEYxb0BxkUU64pczGB7bR1k7PMPDCLum
+t4TjQASqvjPFdL1vGCx2RWTq3El5yZzx3So2TYztWJpR0TpIkPxTQfLOdhjrJqG5Bza
CdhPKDanJR0I4qYx/dsQc2XHSHPD7euZi3/x+8znWKIwUaqMzI7S/Zb1VEVBbA6q6fQ0
wwOaYRukkvy3tdPptSH/ur3uipQ7DclTWPMkK+e/0KNCtcNV+DBQQnEfmfYYGyriFoy9
7gr6Af3tCOnsow5jf3BN0JDlrSVyjuYSllb6tf32mf/ejqmwfeOdyW6ITBTPDObRSekx
TKLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=+e7/nfNGNU5f3z/A9sAKRiDQbC0lvkhqC7HGvdscGQ8=;
b=apbCU5bc7y9xOmq5ftz3kRfvQO8JeBtTqnm7X5TlEMwrOiUyue/fHvx6xli6V/Zqf+
zQKpZ56QayluYxEPBtUUgJx3FpHu588i7aOIDWF0oclVqNWLNf6RVhIe09fw066+15eR
UMEaNEyb3eIwk3UdtDri8uNaE45duppkTXEkX/Io7WEROja1MnE1NZYfl3ucVvY6vkJJ
nvqZspw2SbimRyKXrZW4iQXEFIBgi4tqTW8EiN1qL989j+MDQjm7yu3aHn43f71EvSZv
iSydYmqyJY1ZNNHGu01fsrE74PCYIqr8g1vJBo6EQjHF8/E/BjnMPmwlesTcGLRwCzID
NILw==
X-Gm-Message-State: AOAM532fktk5lDk4qRib5fDI+mslVBOJNWmQcnHEE7NtFSgDDDfe0vQo
gJYbRCbZpirH4s8Z6GkJAbjySRMswU18XQYheK5Eue+M
X-Google-Smtp-Source: ABdhPJzzA0JYoapxyH0ZEgmA57PdEopci7erAQPDL33j9jMrAZeVJ0Hm7EuVIpeXjL4p9SsycL1mhQ/o8tA820Q7wfs=
X-Received: by 2002:a50:aadd:: with SMTP id r29mr8162237edc.219.1598325340265;
Mon, 24 Aug 2020 20:15:40 -0700 (PDT)
MIME-Version: 1.0
From: conjaroy <conjaroy@HIDDEN>
Date: Mon, 24 Aug 2020 23:15:04 -0400
Message-ID: <CABWzUjWkKJkAhJi8MMC1SiSZBPjZBBMgbRk7DavR9QQXhhfRDA@HIDDEN>
Subject: Re: Container with openssh-service requires sshd user on the host
To: 41575 <at> debbugs.gnu.org
Content-Type: multipart/alternative; boundary="00000000000024622a05adab1e78"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 41575
X-Mailman-Approved-At: Tue, 25 Aug 2020 01:08:50 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--00000000000024622a05adab1e78
Content-Type: text/plain; charset="UTF-8"
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
--00000000000024622a05adab1e78
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I've observed this error under similar circumstan=
ces: launching a <span>guix system container script with network sharing en=
abled, on a foreign disto (Debian 10) with nscd running.</span></div><div><=
br></div><div>Using `strace -f /gnu/store/...-run-container`, we can observ=
e the container's lookup of user accounts via the foreign distro's =
nscd socket:<br></div><div><br></div><div>[pid 16582] socket(AF_UNIX, SOCK_=
STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) =3D 11<br>[pid 16582] connect(11, {sa=
_family=3DAF_UNIX, sun_path=3D"/var/run/nscd/socket"}, 110) =3D 0=
<br>[pid 16582] sendto(11, "\2\0\0\0\0\0\0\0\t\0\0\0postgres\0", =
21, MSG_NOSIGNAL, NULL, 0) =3D 21<br>[pid 16582] poll([{fd=3D11, events=3DP=
OLLIN|POLLERR|POLLHUP}], 1, 5000) =3D 1 ([{fd=3D11, revents=3DPOLLIN}])<br>=
[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<br>[pid 16582] close(=
11) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0</d=
iv><div><br></div><div><div>Since the user ("postgres") is indeed=
missing in the foreign disto, the lookup fails. In this case, disabling ns=
cd on the foreign distro allowed the container script to run without error.=
<br></div><div><br></div><div>Based on comments in <a href=3D"https://issu=
es.guix.info/issue/28128" target=3D"_blank">https://issues.guix.info/issue/=
28128</a>, I see that it was a deliberate choice to bind-mount the foreign =
distro's nscd socket inside the container (instead of starting a separa=
te containerized nscd instance). But I'm having trouble seeing why it&#=
39;s acceptable to leak state from the foreign distro's user space into=
the container. Is there something I'm missing?</div><div><br></div><di=
v>Cheers,</div><div><br></div><div>Jason<br></div></div><div><span><span></=
span></span></div></div>
--00000000000024622a05adab1e78--
bug-guix@HIDDEN:bug#41575; Package guix.
Full text available.
Received: (at submit) by debbugs.gnu.org; 28 May 2020 09:20:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 28 05:20:55 2020
Received: from localhost ([127.0.0.1]:50984 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jeEid-0006zu-J9
for submit <at> debbugs.gnu.org; Thu, 28 May 2020 05:20:55 -0400
Received: from lists.gnu.org ([209.51.188.17]:46732)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <edk@HIDDEN>) id 1jeEic-0006zm-Ey
for submit <at> debbugs.gnu.org; Thu, 28 May 2020 05:20:54 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:35218)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <edk@HIDDEN>)
id 1jeEic-0003Fn-9Q
for bug-guix@HIDDEN; Thu, 28 May 2020 05:20:54 -0400
Received: from sender4-op-o11.zoho.com ([136.143.188.11]:17144)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
(Exim 4.90_1) (envelope-from <edk@HIDDEN>)
id 1jeEia-0004NL-D7
for bug-guix@HIDDEN; Thu, 28 May 2020 05:20:53 -0400
ARC-Seal: i=1; a=rsa-sha256; t=1590657647; cv=none;
d=zohomail.com; s=zohoarc;
b=ZREpzXgiRkEaCrNVp0DYBA37uoKHFPCK/01VFlYPxhK0X7GsGoBwZcUgrXudK1mNe0yXS5dOla2M2lV8hwATIfmE2wSFBWym/E3JJaJlr2oujJ2wco9edhky78zaC6LECeSEzXy5EeIjKHm9cnHUeKB9tpwo/tFLTDL4fqdgBiM=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com;
s=zohoarc; t=1590657647;
h=Content-Type:Content-Transfer-Encoding:Date:From:MIME-Version:Message-ID:Subject:To;
bh=+W+JdqwJiJ08FuqR32WeQBMzViYIWMIGk1+8crQcnkE=;
b=mpMDnL2k6kECpKnxtiW0mnXoWMuqP7QUOKPxs6wiSQNX+M3fj/pYP3+/+rnkYErzmjTLj5yaorrmEGChdxlcwDlAnSIc/CgSM+wTPBL+rOXsyL/10R+LRX00vUPL4eJpmAIT5Nx+tlivpm3ioF/4jNGFDRsKfCkSbfWeg25LAeo=
ARC-Authentication-Results: i=1; mx.zohomail.com;
dkim=pass header.i=beaver-labs.com;
spf=pass smtp.mailfrom=edk@HIDDEN;
dmarc=pass header.from=<edk@HIDDEN> header.from=<edk@HIDDEN>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1590657647;
s=zoho; d=beaver-labs.com; i=edk@HIDDEN;
h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding;
bh=+W+JdqwJiJ08FuqR32WeQBMzViYIWMIGk1+8crQcnkE=;
b=G0mG3Veg0k6A4717M+hkDhmAcMmEBOw4iVNyDMHs8BiboKqFum8cO5hEa2yt7S2W
fnxNlwZp/aHsCoSxIwkexCWap7tA6nmZgfEX+xqt1JHgbuZSe0uwu6MJLZ1P5+8koLJ
Klk6X6lnPKDTBg5mZ6KKZnq9jEjAx4GvTaTH4yNg=
Received: from alice.lan (lfbn-idf1-1-1299-119.w90-79.abo.wanadoo.fr
[90.79.23.119]) by mx.zohomail.com
with SMTPS id 1590657645301491.4925981819242;
Thu, 28 May 2020 02:20:45 -0700 (PDT)
User-agent: mu4e 1.4.6; emacs 26.3
From: Edouard Klein <edk@HIDDEN>
To: bug-guix@HIDDEN
Subject: Container with openssh-service requires sshd user on the host
Message-ID: <87mu5s2z6u.fsf@HIDDEN>
Date: Thu, 28 May 2020 11:20:25 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-ZohoMailClient: External
Received-SPF: pass client-ip=136.143.188.11; envelope-from=edk@HIDDEN;
helo=sender4-op-o11.zoho.com
X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/28 05:20:49
X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy]
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,
SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN
X-Spam_action: no action
X-Spam-Score: -1.4 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.4 (--)
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=20
(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 --l=
ogin'
or run 'sudo nsenter -a -t 3934' to get a shell into it.
making '/gnu/store/ml63vj43bv4lrmwdvpm6jqyya24z6zkr-system' the current sys=
tem...
setting up setuid programs in '/run/setuid-programs'...
populating /etc from /gnu/store/a4d90ypz1xylh97ff2b4ysj33hwnmfva-etc...
Backtrace:
12 (primitive-load "/gnu/store/6dvy8acvzkzfba8hjf4nfc3ps2r=E2=80=
=A6")
In gnu/build/linux-container.scm:
297:8 11 (call-with-temporary-directory #<procedure 7f36d0d122d0=E2=80=
=A6>)
325:16 10 (_ _)
62:6 9 (call-with-clean-exit _)
In unknown file:
8 (primitive-load "/gnu/store/ml63vj43bv4lrmwdvpm6jqyya24=E2=80=
=A6")
In ice-9/eval.scm:
619:8 7 (_ #f)
In unknown file:
6 (primitive-load "/gnu/store/zdqjch5xknlhp6dvnl6vdrlfnbm=E2=80=
=A6")
In srfi/srfi-1.scm:
640:9 5 (for-each #<procedure primitive-load (_)> _)
In unknown file:
4 (primitive-load "/gnu/store/y19c6kipzqigz15v4hvy53x2vaz=E2=80=
=A6")
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=E2=80=
=A6>)
In unknown file:
0 (getpw "sshd")
ERROR: In procedure getpw:
In procedure getpw: entry not found
Edouard Klein <edk@HIDDEN>:bug-guix@HIDDEN.
Full text available.bug-guix@HIDDEN:bug#41575; Package guix.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.