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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 3913 invoked from network); 1 Dec 2021 12:34:26 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 1 Dec 2021 12:34:26 -0000 Received: (qmail 7447 invoked by uid 550); 1 Dec 2021 12:34:22 -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 7412 invoked from network); 1 Dec 2021 12:34:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartx-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=TBLRYD0QbJHObTdp+au+tT3+KT0ZPhRZ/Pme1mkeUZU=; b=k5QQpkRj9d40dlMZfkl9p7Oh/vBHe0T6OL4Tn9VEBudFkWfDgd4+X73CG+SoE1hAgi OiUpanGFgXTOiL3jo2GhI8u/qpHwmNs23HHbuP2zkh9QZ0H9kjQR6WyNqiaTsVuDtKod xaCzmG9t2J/gamSHT7wIKVYCWWP1h44Y9CTc+MDOOsgPJEhGKtczPptXifP2K1HIuT7f 2zkL6e9gCTHtKMMuS42ye0coV7n+9+fNw+43cO/wuKGvooBFoMYU+PV24kYP77a9oI85 fSaBBxqve+gZgGAbv7T0WZgPrsQ2tE2DHN2x/3Kabzv4gv1DmOQop1YzVjbzx/RJWnYt ZkxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=TBLRYD0QbJHObTdp+au+tT3+KT0ZPhRZ/Pme1mkeUZU=; b=yIhxf5W7FxOyPbqxkfhGAzvPyF79vIyYPFUO1fnOCO+zkqv2RR00h6P5B8mLYAYbM8 moSV5NVsUtlY/3pywHFgCoV59X5emQDcUVCG44e31lgimyG+whcpVcH/dR34rqD7B3Dv 08l7kw47pkUa+Og43Lx4Xd5WgUCYuW5sdvC7RMa8KIk3gIJevAK0Jx+1GkzE28BP9quq lN6IeKJvQKUXq6T8vS1BRIWYCiXQy5/eyF6zZ/I27Sm4ADLml5iCAytDmXWxWx+fbQp3 gMh/U6X2Idc5L/ehlbWRX4HXQ/RYFHNK/Vyqca2NyAkftj4HWWSBheDVmmLEQ5g4CQtx orng== X-Gm-Message-State: AOAM5326oTr4OV+PPqg4AM9ByGPUmjoa6fCCuHWo2JsqsYzdSKZ9TlSa lArl+LHcoWIlU+KdHeb3Gy4qaYWqbIF3GRzZYBpg4zgqJ79bKw== X-Google-Smtp-Source: ABdhPJze2Qm8jyN/haDJH926eh7sxgferMgQpAg5PwhDwFr36CcxQ1kRjJ6e6jAaaV2Uepn1wl3upsxVOsuIE26Lbfo= X-Received: by 2002:a05:651c:218:: with SMTP id y24mr5230923ljn.50.1638362050411; Wed, 01 Dec 2021 04:34:10 -0800 (PST) MIME-Version: 1.0 References: <20211015122000.2490-1-kaihang.zhang@smartx.com> In-Reply-To: <20211015122000.2490-1-kaihang.zhang@smartx.com> From: Kaihang Zhang Date: Wed, 1 Dec 2021 20:33:58 +0800 Message-ID: To: musl@lists.openwall.com, care <2010267516@qq.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [musl] Re: [PATCH v2] fix: Truncate the too-long mntent in function getmntent_r The behavior of getmntent_r in glibc. If the buffer is too samll for a line, the line will be truncated, glibc uses wrong data for this line. However, there is no opportunity for the developer to realise a mistake they made by supplying too small buffer, hence there is no chance of recovering from it. The user gets the wrong data and doesn't realize it. The behavior of getmntent_r in musl libc. If the buffer is too small for a line, it will set errno to ERANGE and then exit. And the user can retry with a bigger buffer. However, the current interface doesn't allow trying again to read the too-long entry, since it will just have moved to the next one, the too-long entry data will be lost. Maybe fseek(f, -fgets_result, SEEK_CUR) could be used to rewind until the start of the line, but the function would just loop eternally with too short a buffer. For example, a mount entry has 2000 bytes, the size of buffer is 256 bytes, if errno is ERANGE i will retry use buffer size 512, 768, 1024, 1280, 1536, 1792, 2048... I have to try at least 8 times to get the next mount entries. In my opinion, it's ok to truncate the too-long entry (musl libc will even lose it ! ) instead exiting. And the errno will be set to ERANGE in order to let uesr realise this mistake, but as i know the user can only retry from the beginning of the file, that bothers me somehow. It=E2=80=98s up to the user to decide to retry or not. If the user doesn't care about the too-long entry or the discarded contents of it, there is no need to retry. Othrewise, retry from the beginning of the file. On Fri, Oct 15, 2021 at 8:20 PM Kaihang Zhang wr= ote: > > In function getmntent_r in source misc/mntent.c, entry that is too long > will be truncated rather than discarded. The caller can tell by errno > whether the supplied buffer is too small, and retry from the beginning > of the file. > --- > src/misc/mntent.c | 53 +++++++++++++++++++++++++++++------------------ > 1 file changed, 33 insertions(+), 20 deletions(-) > > diff --git a/src/misc/mntent.c b/src/misc/mntent.c > index eabb8200..085ce45d 100644 > --- a/src/misc/mntent.c > +++ b/src/misc/mntent.c > @@ -21,12 +21,12 @@ int endmntent(FILE *f) > > struct mntent *getmntent_r(FILE *f, struct mntent *mnt, char *linebuf, i= nt buflen) > { > - int cnt, n[8], use_internal =3D (linebuf =3D=3D SENTINEL); > - > - mnt->mnt_freq =3D 0; > - mnt->mnt_passno =3D 0; > + int use_internal =3D (linebuf =3D=3D SENTINEL); > + char *sub; > > do { > + char *end_ptr; > + > if (use_internal) { > getline(&internal_buf, &internal_bufsize, f); > linebuf =3D internal_buf; > @@ -34,25 +34,38 @@ struct mntent *getmntent_r(FILE *f, struct mntent *mn= t, char *linebuf, int bufle > fgets(linebuf, buflen, f); > } > if (feof(f) || ferror(f)) return 0; > - if (!strchr(linebuf, '\n')) { > + > + end_ptr =3D strchr(linebuf, '\n'); > + if (end_ptr !=3D NULL) { > + while ((end_ptr[-1] =3D=3D ' ' || end_ptr[-1] =3D= =3D '\t') && end_ptr !=3D linebuf) end_ptr--; > + *end_ptr =3D '\0'; > + } else { > fscanf(f, "%*[^\n]%*[\n]"); > errno =3D ERANGE; > - return 0; > } > - cnt =3D sscanf(linebuf, " %n%*s%n %n%*s%n %n%*s%n %n%*s%n= %d %d", > - n, n+1, n+2, n+3, n+4, n+5, n+6, n+7, > - &mnt->mnt_freq, &mnt->mnt_passno); > - } while (cnt < 2 || linebuf[n[0]] =3D=3D '#'); > - > - linebuf[n[1]] =3D 0; > - linebuf[n[3]] =3D 0; > - linebuf[n[5]] =3D 0; > - linebuf[n[7]] =3D 0; > - > - mnt->mnt_fsname =3D linebuf+n[0]; > - mnt->mnt_dir =3D linebuf+n[2]; > - mnt->mnt_type =3D linebuf+n[4]; > - mnt->mnt_opts =3D linebuf+n[6]; > + > + linebuf +=3D strspn(linebuf, " \t"); > + } while (linebuf[0] =3D=3D '\0' || linebuf[0] =3D=3D '#'); > + > + mnt->mnt_fsname =3D strsep(&linebuf, " \t"); > + > + if (linebuf) linebuf +=3D strspn(linebuf, " \t"); > + sub =3D strsep(&linebuf, " \t"); > + mnt->mnt_dir =3D sub ? sub : (char *) ""; > + > + if (linebuf) linebuf +=3D strspn(linebuf, " \t"); > + sub =3D strsep (&linebuf, " \t"); > + mnt->mnt_type =3D sub ? sub : (char *) ""; > + > + if (linebuf) linebuf +=3D strspn(linebuf, " \t"); > + sub =3D strsep(&linebuf, " \t"); > + mnt->mnt_opts =3D sub ? sub : (char *) ""; > + > + switch (linebuf ? sscanf(linebuf, " %d %d", &mnt->mnt_freq, &mnt-= >mnt_passno) : 0) { > + case 0: mnt->mnt_freq =3D 0; > + case 1: mnt->mnt_passno =3D 0; > + case 2: break; > + } > > return mnt; > } > -- > 2.25.4 > --=20 mail=EF=BC=9Akaihang.zhang@smartx.com tell=EF=BC=9A15196469611 The SmartX email address is only for business purpose. Any sent message that is not related to the business is not authorized or permitted by SmartX. =E6=9C=AC=E9=82=AE=E7=AE=B1=E4=B8=BA=E5=8C=97=E4=BA=AC=E5=BF=97=E5=87=8C=E6= =B5=B7=E7=BA=B3=E7=A7=91=E6=8A=80=E6=9C=89=E9=99=90=E5=85=AC=E5=8F=B8=EF=BC= =88SmartX=EF=BC=89=E5=B7=A5=E4=BD=9C=E9=82=AE=E7=AE=B1. =E5=A6=82=E6=9C=AC= =E9=82=AE=E7=AE=B1=E5=8F=91=E5=87=BA=E7=9A=84=E9=82=AE=E4=BB=B6=E4=B8=8E=E5= =B7=A5=E4=BD=9C=E6=97=A0=E5=85=B3,=E8=AF=A5=E9=82=AE=E4=BB=B6=E6=9C=AA=E5= =BE=97=E5=88=B0=E6=9C=AC=E5=85=AC=E5=8F=B8=E4=BB=BB=E4=BD=95=E7=9A=84=E6=98= =8E=E7=A4=BA=E6=88=96=E9=BB=98=E7=A4=BA=E7=9A=84=E6=8E=88=E6=9D=83.