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.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, 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 30585 invoked from network); 15 Oct 2021 07:20:22 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 15 Oct 2021 07:20:22 -0000 Received: (qmail 18118 invoked by uid 550); 15 Oct 2021 07:20:19 -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 18084 invoked from network); 15 Oct 2021 07:20:18 -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 :cc:content-transfer-encoding; bh=AbGQBB50Mph9XZfc5oSiJWDkUTe6CXY5gk33nAQMzfQ=; b=CRibdUS1Leq6VUDIdmqRjcd3Y4/rQGsR7tPq6VFPr+hsOYd2yB3Y5gR+2zJD2b+oDO MAO8lQk69Lg+kxO+kmucCjallhd4sZT0vFWI7LGOcHTyHpraBzj0ivNdvZ/fVRHabZNj 29rAkyMxBaK+ke19gnWnGLXUuhi5/j2P1N1u+OEWThCMbw95QKi8Zlhh7K25zUIjoMXw tLGTH3TPTiJLiinGH56MTxpqjN2frtcnn09zJdEN9VN7NNFQ5DcasjgOaUbU2PxBw66Y brY/Iltn1Is+p6pvHvY12tSCBiYU7aXgWL0euZh8QBHJ6x4MXPUR6XHeusa/taL4j8RL jEHw== 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:cc:content-transfer-encoding; bh=AbGQBB50Mph9XZfc5oSiJWDkUTe6CXY5gk33nAQMzfQ=; b=MiVbFXngUVnBhUy18DWPL0nBI/vYzIsS26fFwetYtUdcIlfpkrCVQm8xC8GaOB3iej u7G55JoczSG4kQBDidQ04WR/N+y9//jPN2zMBrPhrjh0Cl8OgatBcVmajuSeDmA3Bmwc KMFV0aIcPrj7VFZ/IwydlVDysfCyk+ByR1ltJxyZd3/ZSJsBTEhbifI8lCSeraoctMD5 +Vsb4SgBpSMqb3SvcN861GXYjotm9B1ENIkNtM45IZm+z7ru0PHSb3erfZGhd4Agzy0I c9zgKPwRyrSqYNQgUQbeWXFotBgK7aDnm4tD6JJ0ysK21NeDEqnspeSJy9jxLQeIYGYI zHxw== X-Gm-Message-State: AOAM531z73DUJOyBI4yFc0q4kH6tOGv2+35Tu6aUgEAsSXIBrz7pCUdY 4qvilmB3A2bpXrcrt/uhKQmFM/sPKhgP2pG0ULOKAA== X-Google-Smtp-Source: ABdhPJyR+7srTG5muNS7pm00Yh1MquBTie5cx+w60PeVOhaMxTXu9cI8l5b1mTFrO4jdHSvBYk2g8GjNYIk/7SqjxRY= X-Received: by 2002:a2e:8948:: with SMTP id b8mr10980748ljk.499.1634282407352; Fri, 15 Oct 2021 00:20:07 -0700 (PDT) MIME-Version: 1.0 References: <20211012023643.44509-1-kaihang.zhang@smartx.com> <0100017c7287622f-cceed952-52dc-4c02-b1af-b3943a41203c-000000@email.amazonses.com> <20211012125942.GH7074@brightrain.aerifal.cx> In-Reply-To: <20211012125942.GH7074@brightrain.aerifal.cx> From: Kaihang Zhang Date: Fri, 15 Oct 2021 15:19:56 +0800 Message-ID: To: Rich Felker Cc: "(GalaxyMaster)" , musl@lists.openwall.com, care <2010267516@qq.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] [PATCH] fix: Assign default value to mntent when linebuf is too small On Tue, Oct 12, 2021 at 8:59 PM Rich Felker wrote: > > On Tue, Oct 12, 2021 at 03:24:07AM +0000, (GalaxyMaster) wrote: > > Kaihang, > > > > On Mon, Oct 11, 2021 at 10:36:43PM -0400, Kaihang Zhang wrote: > > > Function getmntent_r in source misc/mntent.c will do what glibc users > > > expect. The rest of the line will be discarded when can not be read > > > into linebuf, and the fields of struct mntent will be assigned to emp= ty > > > string or zero when can not be found in linebuf, instead of setting > > > errno to ERANGE and exiting. > > > > Although this patch is on a similar topic as mine (changing the behavio= ur of > > get*ent() funnctions), I think the change you are describing is conside= rable. > > > > I would expect a function such as getmntent_r() which takes a user prov= ided > > buffer to fail and set ERANGE if the provided buffer is not enough to h= old > > the line. This gives the developer an opportunity to recover, e.g. to > > re-allocate a bigger buffer and try again. > > > > In your proposal, I see two issues: > > > > 1. There is no feedback to the developer, so they have no idea whether = the > > information they've got from the function was truncated or not (and = what > > good does a truncated mnt line bring?); > > 2. There is no opportunity for the developer to realise a mistake they = made > > by supplying too small buffer, hence there is no chance of recoverin= g > > from it. > > > > It is just my opinion and I would love to see other comments, since I h= ave > > not stumbled upon your use case yet and am not authoritative on this to= pic. > > Yes. There are actually several conflicting proposed changes to this > (frustratingly underspecified, and with bad behavior by glibc) > function, and so far there's been little engagement between different > people who want it changed/fixed to resolve the differences. I would > really like to see from at least one party who wants it changed a > summary of what the differences are between the different proposals, > what musl is doing now, and what glibc is doing now, and > justifications for why their preferred one is okay (including > capability for applications to recover and not silently use wrong data > -- "glibc lets them silently use wrong data" isn't a justification). > > Rich Give an example to better describe it. The contents of /proc/mounts are like below, the field 'opts' of overlay can be even more longer. > overlay / overlay rw,seclabel,relatime,lowerdir=3D/var/lib/docker/overlay= 2/l/6WSJ5KZAYZO55RQRWFQZNDGPWK:/var/lib/docker/overlay2/l/YS7ZKHUX3JB3F4SQI= JYXXNIYTV:/var/lib/docker/overlay2/l/OWUPK4QNZP7ZOZKERGMTJQW55T:/var/lib/do= cker/overlay2/l/LL7NIEVB5NMPAEJK6SUCXJYRGK,upperdir=3D/var/lib/docker/overl= ay2/2012ae841481001d5eea099c6e84319f88c5079d44eb6a2402397858dd3d22e2/diff,w= orkdir=3D/var/lib/docker/overlay2/2012ae841481001d5eea099c6e84319f88c5079d4= 4eb6a2402397858dd3d22e2/work 0 0 > proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 > cgroup /sys/fs/cgroup/systemd cgroup rw,seclabel,nosuid,nodev,noexec,rela= time,xattr,release_agent=3D/usr/lib/systemd/systemd-cgroups-agent,name=3Dsy= stemd 0 0 1. The behavior of getmntent_r in glibc. If the buffer is too samll for the line 'overlay', the line will be trunca= ted. Glibc uses wrong data for this line. But i only care about cgroup info, and i am sure that the buffer capacity is sufficient for cgroup. The mnten= t for cgroup is exactly what i want. There is no need to retry use a bigger buffer. However, as galaxy wrote: > There is no opportunity for the developer to realise a mistake they m= ade > 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. 2. The behavior of getmntent_r in musl libc. If the buffer is too small for the line 'overlay', it will set errno to ERANGE and then exit. And the user can retry with a bigger buffer. However, as ericonr ever said: > The current interface doesn't allow trying again to read the too-long e= ntry, > 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. > The overlay 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 cgroup info ! :( 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. Kaihang