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,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 29921 invoked from network); 4 Aug 2020 07:03:26 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 4 Aug 2020 07:03:26 -0000 Received: (qmail 21657 invoked by uid 550); 4 Aug 2020 07:03:21 -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 21639 invoked from network); 4 Aug 2020 07:03:21 -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 :content-transfer-encoding; bh=HKyRgsB2HUsaSO1plyUNnKv+z0EnKHw0ycI+a8mPnxc=; b=ssE6QpDFRDTsNZzoGWzcHTI6y67eQBSPqUhURjwiGUM2ODb5w2D96RUaGEzW+BJMFq pZwx0zMPJCSRhOnK0UcgqnqqS975LrmuTNDMKbCk4urU7kHMB/gwB/Zj+PuHpvsx6Gb7 QdoITGj3Xx49urNMgAqcg1c7ZU8fLX5hyo5PvprssyufrB5fXTZjrYzy7xw6kWesf8NY XvjzDplOvO5oWvZLPp546Lo1m1c3HP7ZBODcrjTs9c4UqIlXjK02PTFT1lvSLTAU0+/4 GP3fxSUBuioSLI3NkI/0nyh/JGF9g3RqsPetJDXBiTDnSTYQyA2KCwSXH1WeusOrvg0G H0Ww== 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:content-transfer-encoding; bh=HKyRgsB2HUsaSO1plyUNnKv+z0EnKHw0ycI+a8mPnxc=; b=kRSu4MU0r26vbk6ita2DT1VDJ/phHOjqdSM2wBK9E+sGzjPMbjUkzmGxwLsDTz/KXE ZO3odznB7hw1NV2NxyqT5OtItRAF1uKC345HxCninvQkjt71ECSv0ctZOtSrIyz1YLiU AmC9mmNybiaI/dbkFdgIF6TVv3QZ1VLuPIQcSPOtD/cvlzPjw22TiqXihSphfwz4pmmx gbZDXAzGwKU/fAk4zMd5lb2MFU/O6QnGJrs8CwG1uckc8jIZptZnSFx0UQQr5oIEGzOe cViAHIVkzHsokbxPr0KAv4cnEczyYWm2NvvUPGm6hp5lD410uGmmHRgXM6BkpAHBXKl9 mzhw== X-Gm-Message-State: AOAM533Lrf7fecA9mlajxr3DSU0XDR/v3UOW85CPbe8p7hICgsSGkOHm S1YvmTfcZScrrQVe2a5Jim0ejFhJd2QaTCtl2PlgnFXh X-Google-Smtp-Source: ABdhPJxZw3kA7jw+Mgbk4BKdfPIQOU3pKW1pnxn7kuIvol5GFA1pTFAD7GGWnVoIdLALoRTfPuz5E2AvtcD+MFU6juU= X-Received: by 2002:a67:ec0f:: with SMTP id d15mr14204989vso.11.1596524588775; Tue, 04 Aug 2020 00:03:08 -0700 (PDT) MIME-Version: 1.0 References: <20200803205529.2232-1-ericonr@disroot.org> <20200804030201.GG6949@brightrain.aerifal.cx> In-Reply-To: <20200804030201.GG6949@brightrain.aerifal.cx> From: Andre McCurdy Date: Tue, 4 Aug 2020 00:02:58 -0700 Message-ID: To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] [PATCH] extend gethostid beyond a stub On Mon, Aug 3, 2020 at 8:02 PM Rich Felker wrote: > > On Mon, Aug 03, 2020 at 05:55:29PM -0300, =C3=89rico Rolim wrote: > > From: =C3=89rico Rolim > > > > Implement part of the glibc behavior, where the 32-bit identifier store= d > > in /etc/hostid, if the file exists, is returned. If this file doesn't > > contain at least 32 bits or can't be opened for some reason, return 0. > > --- > > src/misc/gethostid.c | 15 ++++++++++++++- > > 1 file changed, 14 insertions(+), 1 deletion(-) > > > > diff --git a/src/misc/gethostid.c b/src/misc/gethostid.c > > index 25bb35db..e2e98b99 100644 > > --- a/src/misc/gethostid.c > > +++ b/src/misc/gethostid.c > > @@ -1,6 +1,19 @@ > > #include > > +#include > > > > long gethostid() > > { > > - return 0; > > + FILE *f; > > + unsigned char hostid[4]; > > + long rv =3D 0; > > + > > + f =3D fopen("/etc/hostid", "reb"); > > + if (f) { > > + if (fread(hostid, 1, 4, f) =3D=3D 4) { > > + rv =3D (hostid[3] << 24) | (hostid[2] << 16) | (h= ostid[1] << 8) | hostid[0]; > > + } > > + fclose(f); > > + } > > + > > + return rv; > > } > > -- > > 2.28.0 > > I somewhat dislike the use of stdio here, but this is something of a > junk function that's not really worth writing read() retry loop, etc. > > hostid[3]<<24 is UB due to integer overflow (the promoted type is int, > a signed type). This could be fixed via promotion to unsigned before > the shift, but rather than constructing the value manually like this > I'd probably lean towards reading it into a uint32_t object x then > returning ntohl(x). The glibc implementation appears to read and write directly into an int32_t variable, without any endianness conversion. To be interoperable with /etc/hostid files created by glibc shouldn't musl skip the ntohl() and just return x ? > It's unfortunate that fopen can fail for spurious reasons like ENOMEM > or EMFILE/ENFILE, and that gethostid has no way of reporting this > error rather than returning the wrong id, but this seems like a > fundamental design bug in the interface and not something we can fix, > at least not while using the existing design with data in a file. I > think it could be avoided by using readlink() and storing the id in > the contents of a symlink, which should have no spurious failure > modes, but I'm not really keen on inventing a new convention for this > fundamentally-broken function. > > So overall this looks pretty good. I'll revisit it after release and > see if anyone else has thoughts on it in the mean time.