From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29639 invoked from network); 25 Oct 2020 06:21:28 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 25 Oct 2020 06:21:28 -0000 Received: (qmail 21526 invoked by uid 550); 25 Oct 2020 06:21:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 20472 invoked from network); 25 Oct 2020 06:21:25 -0000 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; bh=1+JZVlVgvkGHchpzi8fDiKzC8gt0gg0P5/N8ujQAPac=; b=Pu7NlZ7Iyv0qVQtT6NNMc4CD4dAzqtCok4J6RAqvM6/QwB9AeXG13Zvw2sB0WHSLMw X5jPzI69Au9CLZ52PNDsQr3fHIUoACDW1MtJOrbvexcqvFd2ERz1DazMCBlXDf5knwE5 ogngjoaaJOARRJ36BY9No7V02Z6qarL9CJw3kWvbE11V+/wyrMeLz+eSr/Pra2gTMlne H5kZnm+2HvUazXedhE9RO7DwHkfBHZZ9ASs/DL4pSd8YR/+mKfcpWjx3YeIn7GIuOlVo VHilly2AI5g1kt1vfoQHL00Emj4uGFPzMclMkZNurSqeFV1+byFuqrCe5Mej+0Z7Vg4O +cXg== 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; bh=1+JZVlVgvkGHchpzi8fDiKzC8gt0gg0P5/N8ujQAPac=; b=ZcS9NbNwXZGb1vWyPcDX88XotsAXZYp5nJbFKtLxyKmlMvGPDooGNEM3hVOJ8agT7A gYqAxmNsxqkYqXhLxIbJUE3u3k3iGMMmajRvoNpp+9/ZGg39F/dc4RARAgd2U7Oz4NR9 Jmz943opGfOky51H9BEfCzV6Y5OKRhU/Qc9MTfvgM1IaNM4ed9OtkrOqUsCRH18sw7B0 iK2XKI7mnaxlwvjhhaTtgPmLFgHJZDEa2a2voD1Xek3pjQs46tkSzVqpJcBjepBLRyX2 NSXjO4pdG3i7iY+ysn0PPlsZl/0GilhFBYD5X97M6wIxR9HQ2vH92PGMYnN8KVm4/auB 4zzw== X-Gm-Message-State: AOAM533mncIMpdpGdUGbuBvO8mB+VXU6/2hyLTUMA/ywmddrbzKEwkgx avqobBBfek12Fngy7klTTPPjJCG094VsI9lTwwLI6EfUnSQ= X-Google-Smtp-Source: ABdhPJwoSN44tIuEPmbfdAqQ/gop2huGlxPHBMMTyOoXIeteN2YGoRXLBNLcOyDzOqIeW3mHZrxRRIcXyBNsd1kqSDQ= X-Received: by 2002:aca:4d44:: with SMTP id a65mr6588713oib.144.1603606873392; Sat, 24 Oct 2020 23:21:13 -0700 (PDT) MIME-Version: 1.0 References: <20201003023703.GT17637@brightrain.aerifal.cx> <20201009203919.GA17637@brightrain.aerifal.cx> In-Reply-To: From: Static Php Date: Sun, 25 Oct 2020 14:21:02 +0800 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="0000000000000c481305b278d2f7" Subject: Re: [musl] runtime error: initgroups(www-data, 33) failed (5: I/O error) --0000000000000c481305b278d2f7 Content-Type: text/plain; charset="UTF-8" I put the patch file into folder patches/musl-1.2.1 and rebuild, get the same results. On Sun, Oct 25, 2020 at 2:03 PM Static Php wrote: > I am not sure which step I made wrong, but I still get this error. > > 1. make clean > 2. make musl-1.2.1 > 3. patch -p1 < ../patches/musl-1.2.0/0002-group.diff > 4. make all -j8 > 5. sudo make install > > then I relink my php, test at old server and get the same result. > > On Sat, Oct 10, 2020 at 4:39 AM Rich Felker wrote: > >> On Fri, Oct 02, 2020 at 10:37:03PM -0400, Rich Felker wrote: >> > On Sat, Oct 03, 2020 at 09:06:50AM +0800, Static Php wrote: >> > > I has this runtime error on Ubuntu 18.04.5 LTS, CPU is AMD EPYC >> Processor. >> > > >> > > Kernel: 5.4.0-49-generic #53~18.04.1-Ubuntu (other kernel also has >> this >> > > problem) >> > > >> > > more details: >> https://github.com/richfelker/musl-cross-make/issues/107 >> > > >> > > strace: >> > > >> > > execve("./a.out", ["./a.out"], 0x7fff12cd26d0 /* 20 vars */) = 0 >> > > > >> > > > arch_prctl(ARCH_SET_FS, 0x7ff53bb3b618) = 0 >> > > > >> > > > set_tid_address(0x7ff53bb3bbe8) = 40778 >> > > > >> > > > socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 3 >> > > > >> > > > brk(NULL) = 0x555556f23000 >> > > > >> > > > brk(0x555556f25000) = 0x555556f25000 >> > > > >> > > > mmap(0x555556f23000, 4096, PROT_NONE, >> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, >> > > > -1, 0) = 0x555556f23000 >> > > > >> > > > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, >> -1, 0) = >> > > > 0x7ff53bb39000 >> > > > >> > > > connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, >> 24) = 0 >> > > > >> > > > sendmsg(3, {msg_name=NULL, msg_namelen=0, >> > > > msg_iov=[{iov_base="\2\0\0\0\17\0\0\0\t\0\0\0", iov_len=12}, >> > > > {iov_base="www-data\0", iov_len=9}], msg_iovlen=2, msg_controllen=0, >> > > > msg_flags=0}, MSG_NOSIGNAL) = 21 >> > > > >> > > > readv(3, [{iov_base="\2\0\0\0\1\0\0\0\0\0\0", iov_len=11}, >> {iov_base="\0", >> > > > iov_len=1024}], 2) = 12 >> > > > >> > > > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, >> -1, 0) = >> > > > 0x7ff53bb38000 >> > > > >> > > > close(3) = 0 >> > > > >> > > > munmap(0x7ff53bb39000, 4096) = 0 >> > > > >> > > > munmap(0x7ff53bb38000, 4096) = 0 >> > > > >> > > > ioctl(1, TIOCGWINSZ, {ws_row=59, ws_col=225, ws_xpixel=1575, >> > > > ws_ypixel=826}) = 0 >> > > > >> > > > writev(1, [{iov_base="err=-1, errno=5", iov_len=15}, {iov_base="\n", >> > > > iov_len=1}], 2err=-1, errno=5 >> > > > >> > > > ) = 16 >> > > > >> > > > exit_group(0) = ? >> > > > >> > > > +++ exited with 0 +++ >> > > > >> > >> > Ah, this looks like a bug in musl causing a zero-groups response from >> > nscd to be interpreted as an error rather than success with no >> > members: >> > >> > if (!fread(nscdbuf, sizeof(*nscdbuf)*resp[INITGRNGRPS], 1, f)) { >> > if (!ferror(f)) errno = EIO; >> > goto cleanup; >> > } >> > >> > The problem is that this code was written assuming the fread call >> > returns 1 on success, but fread has a stupid corner case (which we >> > used to get wrong) where a zero-length read is required by the >> > standard to return 0 even though logically it should return nmemb. >> > >> > You can work around the problem by adding www-data to a useless dummy >> > group. I'll prepare a patch for musl, though, and post it here as a >> > follow-up soon. >> > >> > Thanks for the report! >> >> I think the attached patch should work, but it's not tested since I >> dont have an environment with nscd handy. >> >> Rich >> > --0000000000000c481305b278d2f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I put the patch file into folder patches/musl-1.2.1 and re= build, get the same results.

On Sun, Oct 25, 2020 at 2:03 PM Static Php= <phpstatic.com@gmail.com= > wrote:
I am not sure which step I made wrong, but I still get this er= ror.

1. make clean
2. make=C2=A0musl-1.2.1
3.=C2=A0patch -p1 < ../patches/musl-1.2.0/0002-group.diff=C2=A0<= /span>
4. make all -j8
5. sudo make install

then I relink my php, test at=C2=A0 old server and get th= e same=C2=A0result.

= On Sat, Oct 10, 2020 at 4:39 AM Rich Felker <dalias@libc.org> wrote:
On Fri, Oct 02, 2020 at 10:37:03PM= -0400, Rich Felker wrote:
> On Sat, Oct 03, 2020 at 09:06:50AM +0800, Static Php wrote:
> > I has this runtime error on Ubuntu 18.04.5 LTS, CPU is AMD EPYC P= rocessor.
> >
> > Kernel: 5.4.0-49-generic #53~18.04.1-Ubuntu (other kernel also ha= s this
> > problem)
> >
> > more details: https://github.com/r= ichfelker/musl-cross-make/issues/107
> >
> > strace:
> >
> > execve("./a.out", ["./a.out"], 0x7fff12cd26d0= /* 20 vars */) =3D 0
> > >
> > > arch_prctl(ARCH_SET_FS, 0x7ff53bb3b618) =3D 0
> > >
> > > set_tid_address(0x7ff53bb3bbe8)=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0=3D 40778
> > >
> > > socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) =3D 3
> > >
> > > brk(NULL)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 0x555556f= 23000
> > >
> > > brk(0x555556f25000)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 0x555556f25000
> > >
> > > mmap(0x555556f23000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|= MAP_ANONYMOUS,
> > > -1, 0) =3D 0x555556f23000
> > >
> > > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONY= MOUS, -1, 0) =3D
> > > 0x7ff53bb39000
> > >
> > > connect(3, {sa_family=3DAF_UNIX, sun_path=3D"/var/run/n= scd/socket"}, 24) =3D 0
> > >
> > > sendmsg(3, {msg_name=3DNULL, msg_namelen=3D0,
> > > msg_iov=3D[{iov_base=3D"\2\0\0\0\17\0\0\0\t\0\0\0"= , iov_len=3D12},
> > > {iov_base=3D"www-data\0", iov_len=3D9}], msg_iovle= n=3D2, msg_controllen=3D0,
> > > msg_flags=3D0}, MSG_NOSIGNAL) =3D 21
> > >
> > > readv(3, [{iov_base=3D"\2\0\0\0\1\0\0\0\0\0\0", io= v_len=3D11}, {iov_base=3D"\0",
> > > iov_len=3D1024}], 2) =3D 12
> > >
> > > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONY= MOUS, -1, 0) =3D
> > > 0x7ff53bb38000
> > >
> > > close(3)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0
> > >
> > > munmap(0x7ff53bb39000, 4096)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =3D 0
> > >
> > > munmap(0x7ff53bb38000, 4096)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =3D 0
> > >
> > > ioctl(1, TIOCGWINSZ, {ws_row=3D59, ws_col=3D225, ws_xpixel= =3D1575,
> > > ws_ypixel=3D826}) =3D 0
> > >
> > > writev(1, [{iov_base=3D"err=3D-1, errno=3D5", iov_= len=3D15}, {iov_base=3D"\n",
> > > iov_len=3D1}], 2err=3D-1, errno=3D5
> > >
> > > ) =3D 16
> > >
> > > exit_group(0)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D ?
> > >
> > > +++ exited with 0 +++
> > >
>
> Ah, this looks like a bug in musl causing a zero-groups response from<= br> > nscd to be interpreted as an error rather than success with no
> members:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0if (!fread(nscdbuf, sizeof(*nscdbuf)*resp[IN= ITGRNGRPS], 1, f)) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!ferror(f)) = errno =3D EIO;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0goto cleanup; >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>
> The problem is that this code was written assuming the fread call
> returns 1 on success, but fread has a stupid corner case (which we
> used to get wrong) where a zero-length read is required by the
> standard to return 0 even though logically it should return nmemb.
>
> You can work around the problem by adding www-data to a useless dummy<= br> > group. I'll prepare a patch for musl, though, and post it here as = a
> follow-up soon.
>
> Thanks for the report!

I think the attached patch should work, but it's not tested since I
dont have an environment with nscd handy.

Rich
--0000000000000c481305b278d2f7--