From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 3c37314a for ; Wed, 22 Jan 2020 21:56:13 +0000 (UTC) Received: (qmail 31840 invoked by uid 550); 22 Jan 2020 21:56:11 -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 31822 invoked from network); 22 Jan 2020 21:56:11 -0000 X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu To: Florian Weimer , Rich Felker Cc: musl@lists.openwall.com, 39236@debbugs.gnu.org References: <20200122141557.GA8157@brightrain.aerifal.cx> <87ftg7k1at.fsf@oldenburg2.str.redhat.com> <20200122144243.GZ30412@brightrain.aerifal.cx> <87a76fjzpx.fsf@oldenburg2.str.redhat.com> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Wed, 22 Jan 2020 13:55:57 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <87a76fjzpx.fsf@oldenburg2.str.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: bug#39236: [musl] coreutils cp mishandles error return from lchmod On 1/22/20 7:08 AM, Florian Weimer wrote: > I think you misread what I wrote: lchmod*always* returns ENOSYS. Even > if the file is not a symbolic link. Likewise, fchmodat with > AT_SYMLINK_NOFOLLOW *always* returns ENOTSUP. That's too bad, because coreutils (and many other applications, I expect) assume that lchmod (and fchmodat with AT_SYMLINK_NOFOLLOW) to act like chmod except not follow symlinks, in order to make it less likely that the application will run afoul of a symlink race and chmod the wrong file. Isn't that how the Linux fstatat call behaves? And if so, why does glibc fstatat refuse to support this behavior? To work around this bug, I suppose coreutils etc. should do something like the following: 1. Never use lchmod since the porting nightmare is bad enough without it. 2. On non-glibc systems (or glibc systems where the bug is fixed), use fchmodat with AT_SYMLINK_NOFOLLOW. 3. On glibc systems with the bug, use openat with AT_SYMLINK_NOFOLLOW and O_PATH, and then fchmod the resulting file descriptor. Does this sound right? Or is there some O_PATH gotcha that I haven't thought about? Come to think of it, perhaps the best thing would be to change Gnulib's lchmod and fchmodat modules so that they do what applications expect, even on buggy glibc systems. (Which would be ironic, since Gnulib's main goal is to put wrappers around other libraries so that they look more like glibc.)