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=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 30842 invoked from network); 12 Oct 2021 13:00:01 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 12 Oct 2021 13:00:01 -0000 Received: (qmail 5696 invoked by uid 550); 12 Oct 2021 12:59:58 -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 5660 invoked from network); 12 Oct 2021 12:59:57 -0000 Date: Tue, 12 Oct 2021 08:59:45 -0400 From: Rich Felker To: "(GalaxyMaster)" Cc: musl@lists.openwall.com, 2010267516@qq.com, Kaihang Zhang Message-ID: <20211012125942.GH7074@brightrain.aerifal.cx> References: <20211012023643.44509-1-kaihang.zhang@smartx.com> <0100017c7287622f-cceed952-52dc-4c02-b1af-b3943a41203c-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0100017c7287622f-cceed952-52dc-4c02-b1af-b3943a41203c-000000@email.amazonses.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH] fix: Assign default value to mntent when linebuf is too small 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 empty > > 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 behaviour of > get*ent() funnctions), I think the change you are describing is considerable. > > I would expect a function such as getmntent_r() which takes a user provided > buffer to fail and set ERANGE if the provided buffer is not enough to hold > 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 recovering > from it. > > It is just my opinion and I would love to see other comments, since I have > not stumbled upon your use case yet and am not authoritative on this topic. 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