From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 240A43851C0B; Tue, 18 Aug 2020 21:55:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 240A43851C0B From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug libc/24970] realpath mishandles EOVERFLOW; stat not needed anyway Date: Tue, 18 Aug 2020 21:55:04 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.30 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 21:55:05 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24970 Adhemerval Zanella changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adhemerval.zanella at lina= ro dot o | |rg --- Comment #2 from Adhemerval Zanella --- The EOVERFLOW should not happen with internal LFS call, at least not on Lin= ux (not sure about Hurd). So I am not sure if this really characterize an iss= ue, there are other LFS stat usages that do not handle EOVERFLOW. I also checked the proposed patch and it triggers two regression on stdlib test-canon.c: 94 {"./doesExist/someFile/", 0, "./doesExist/someFile", ENOTDIR}, 95 {"./doesExist/someFile/..", 0, "./doesExist/someFile", ENOTDIR}, The filesystem status prior the calls are: mkdir ("doesExist", 0777) creat ("doesExist/someFile", 0777)=20 For the test at line 94 I could adjust the algorithm to avoid terminate if = the 'start' and 'end' buffer is equal and returning if readlink call returns 'ENOENT'. However, for the case at line 95 I see to easy way to avoid issuing an extra 'readlink' call for each '..' at line 120 to check if the previous component can be really accessed, otherwise the next iteration will check a possible valid path and end early (in the example "doesExist/someFile/.." returns "doesExist/" with the proposed patch). So with the extra 'readlink' call issues on every '..' I am not sure this is really a gain performance-wise. If you have a better strategy how to use 'readlink' and still provide the same semantic for such cases I think it sh= ould be worth, otherwise I think current approach it ok as is. --=20 You are receiving this mail because: You are on the CC list for the bug.=