From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 09:35:40 2020 Received: (at submit) by debbugs.gnu.org; 22 Jan 2020 14:35:40 +0000 Received: from localhost ([127.0.0.1]:49307 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuH6Z-0008IG-W0 for submit@debbugs.gnu.org; Wed, 22 Jan 2020 09:35:40 -0500 Received: from lists.gnu.org ([209.51.188.17]:41002) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuH6X-0008I9-6M for submit@debbugs.gnu.org; Wed, 22 Jan 2020 09:35:38 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60667) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iuH6V-0001e8-Ov for bug-coreutils@gnu.org; Wed, 22 Jan 2020 09:35:36 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iuH6T-00085p-Sk for bug-coreutils@gnu.org; Wed, 22 Jan 2020 09:35:35 -0500 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:49757 helo=us-smtp-delivery-1.mimecast.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iuH6T-00084a-ML for bug-coreutils@gnu.org; Wed, 22 Jan 2020 09:35:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579703731; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fa+uvWeqANcSMjzzWVClZJdS/OnErGIq9duycYoIYnE=; b=TkkVgjxCJz+564g7gdknpTcggAQ+Euu3D1yPmBH8gXMUDvK5djTm9p7bUw2DqdZFjCQY02 vZsUlgs3+CU3qe4/GLSrh+IBdbyoqVMtNNK8SWLomd884NKVuk2ffuGcOqXP9o52Yq0TzH Urr9jrDio1JTu+FlPqTWxnB492S5/nA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-258-D7e9fOYjOwawhIimdHGfIQ-1; Wed, 22 Jan 2020 09:34:22 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3F848100550E; Wed, 22 Jan 2020 14:34:21 +0000 (UTC) Received: from oldenburg2.str.redhat.com (dhcp-192-227.str.redhat.com [10.33.192.227]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 55B5D100EA05; Wed, 22 Jan 2020 14:34:20 +0000 (UTC) From: Florian Weimer To: Rich Felker Subject: Re: [musl] coreutils cp mishandles error return from lchmod References: <20200122141557.GA8157@brightrain.aerifal.cx> Date: Wed, 22 Jan 2020 15:34:18 +0100 In-Reply-To: <20200122141557.GA8157@brightrain.aerifal.cx> (Rich Felker's message of "Wed, 22 Jan 2020 09:15:57 -0500") Message-ID: <87ftg7k1at.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-MC-Unique: D7e9fOYjOwawhIimdHGfIQ-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 207.211.31.81 X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: musl@lists.openwall.com, bug-coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) * Rich Felker: > coreutils should be opting to use the system-provided lchmod, which is > safe, and correctly handling error returns (silently treating > EOPNOTSUPP as success) rather than as hard errors. glibc's lchmod always returns ENOSYS (except on Hurd). I don't know how lchmod is used in coreutils, but I suspect it is not particularly useful. Thanks, Florian From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 10:08:41 2020 Received: (at 39236) by debbugs.gnu.org; 22 Jan 2020 15:08:41 +0000 Received: from localhost ([127.0.0.1]:51085 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuHcW-00017l-UP for submit@debbugs.gnu.org; Wed, 22 Jan 2020 10:08:41 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:46086 helo=us-smtp-1.mimecast.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuHcV-00017Y-42 for 39236@debbugs.gnu.org; Wed, 22 Jan 2020 10:08:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579705713; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IYAHJ29z0WQ1PTv+x2InhspzlPnZqmifdh8VCc9GoB0=; b=SNVKfuTd9kTB3aAoEoMzbzo7lN8JnjBmcASMweQ80AARsR7qf2wXuHyTECC1Zlz8PuvAFk 7N+QbWRi0usw9vZbx30a/r+ffCiongU1XBgc9leP/NQC0Bq5K0NNg8/MgSk36wngai7vmj C8wGwqGAUkndGW6zg+qe+vfGaPSenQs= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-177-c8t5ySplPmmDUBal30tzFg-1; Wed, 22 Jan 2020 10:08:30 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B11EA18AAFA2; Wed, 22 Jan 2020 15:08:28 +0000 (UTC) Received: from oldenburg2.str.redhat.com (dhcp-192-227.str.redhat.com [10.33.192.227]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CD1E11001B35; Wed, 22 Jan 2020 15:08:27 +0000 (UTC) From: Florian Weimer To: Rich Felker Subject: Re: [musl] coreutils cp mishandles error return from lchmod References: <20200122141557.GA8157@brightrain.aerifal.cx> <87ftg7k1at.fsf@oldenburg2.str.redhat.com> <20200122144243.GZ30412@brightrain.aerifal.cx> Date: Wed, 22 Jan 2020 16:08:26 +0100 In-Reply-To: <20200122144243.GZ30412@brightrain.aerifal.cx> (Rich Felker's message of "Wed, 22 Jan 2020 09:42:43 -0500") Message-ID: <87a76fjzpx.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-MC-Unique: c8t5ySplPmmDUBal30tzFg-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 39236 Cc: musl@lists.openwall.com, 39236@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) * Rich Felker: > On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote: >> * Rich Felker: >>=20 >> > coreutils should be opting to use the system-provided lchmod, which is >> > safe, and correctly handling error returns (silently treating >> > EOPNOTSUPP as success) rather than as hard errors. >>=20 >> glibc's lchmod always returns ENOSYS (except on Hurd). I don't know how >> lchmod is used in coreutils, but I suspect it is not particularly >> useful. > > When preserving permissions (cp -p, archive extraction, etc.), you > want lchmod to work correctly just for the purpose of *not* following > the link and thereby unwantedly changing the permissions of the link > target. But, fchmodat with AT_SYMLINK_NOFOLLOW works just as well and > is standard, and that's really what coreutils should be using. 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. The reason for this is that the kernel does not provide a suitable system call to implement this, even though some file systems allow a mode change for symbolic links. I think we can do better, although I should note that each time we implement such emulation in userspace, it comes back to bite us eventually. Thanks, Florian From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 10:33:00 2020 Received: (at 39236) by debbugs.gnu.org; 22 Jan 2020 15:33:00 +0000 Received: from localhost ([127.0.0.1]:51122 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuI04-0001kt-2S for submit@debbugs.gnu.org; Wed, 22 Jan 2020 10:33:00 -0500 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:47420 helo=us-smtp-delivery-1.mimecast.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuI02-0001kf-H3 for 39236@debbugs.gnu.org; Wed, 22 Jan 2020 10:32:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579707172; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lukizSyFTkoCgu6xnxIGPXbkU9xyLUCT9IWiVqolSxo=; b=PDWOvsRcLwvMkTLRDh4cGrxGBOlQpOAfwfR/9xzoJiQre+vg4QXjhrjvm7u7DLsxAiBUfX 58s5tj5NkzaOsSkSZnSr4i+WdyjXsVFHVc9EUCn3DJkWpkbEKSuXXiLl4GqMXzJMuLu8MC skiiXF2WYXgSRrWF5COyHcX9O+CTx/k= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-39-kv-JYc7_ODix7BwjkEwkxg-1; Wed, 22 Jan 2020 10:32:49 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 715A7132908; Wed, 22 Jan 2020 15:32:47 +0000 (UTC) Received: from oldenburg2.str.redhat.com (dhcp-192-227.str.redhat.com [10.33.192.227]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9E2A98BE19; Wed, 22 Jan 2020 15:32:46 +0000 (UTC) From: Florian Weimer To: Rich Felker Subject: Re: [musl] coreutils cp mishandles error return from lchmod References: <20200122141557.GA8157@brightrain.aerifal.cx> <87ftg7k1at.fsf@oldenburg2.str.redhat.com> <20200122144243.GZ30412@brightrain.aerifal.cx> <87a76fjzpx.fsf@oldenburg2.str.redhat.com> <20200122151507.GB30412@brightrain.aerifal.cx> Date: Wed, 22 Jan 2020 16:32:45 +0100 In-Reply-To: <20200122151507.GB30412@brightrain.aerifal.cx> (Rich Felker's message of "Wed, 22 Jan 2020 10:15:07 -0500") Message-ID: <87zhefik0y.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-MC-Unique: kv-JYc7_ODix7BwjkEwkxg-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 39236 Cc: musl@lists.openwall.com, 39236@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) * Rich Felker: > On Wed, Jan 22, 2020 at 04:08:26PM +0100, Florian Weimer wrote: >> * Rich Felker: >>=20 >> > On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote: >> >> * Rich Felker: >> >>=20 >> >> > coreutils should be opting to use the system-provided lchmod, which= is >> >> > safe, and correctly handling error returns (silently treating >> >> > EOPNOTSUPP as success) rather than as hard errors. >> >>=20 >> >> glibc's lchmod always returns ENOSYS (except on Hurd). I don't know = how >> >> lchmod is used in coreutils, but I suspect it is not particularly >> >> useful. >> > >> > When preserving permissions (cp -p, archive extraction, etc.), you >> > want lchmod to work correctly just for the purpose of *not* following >> > the link and thereby unwantedly changing the permissions of the link >> > target. But, fchmodat with AT_SYMLINK_NOFOLLOW works just as well and >> > is standard, and that's really what coreutils should be using. >>=20 >> 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. > > Yes, I understood that. I was going into why there should be a real > implementation, but didn't make it clear that that was what I was > doing. Ah, yes, there should be a real implementation if we can get full lchmod/AT_SYMLINK_NOFOLLOW behavior on file systems that support it. If we can't, I'm not sure if there is a point to it. >> The reason for this is that the kernel does not provide a suitable >> system call to implement this, even though some file systems allow a >> mode change for symbolic links. I think we can do better, although I >> should note that each time we implement such emulation in userspace, it >> comes back to bite us eventually. > > Emulations in userspace that are approximate, have race conditions, > etc. are bad. Ones that are rigorous are good, though. Is there a reason for the S_ISLNK check in the musl implementation? With current kernels, chmod on the proc pseudo-file will not traverse the symbolic link, but I have yet to check if this has always been the case. Thanks, Florian From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 11:00:02 2020 Received: (at submit) by debbugs.gnu.org; 22 Jan 2020 16:00:03 +0000 Received: from localhost ([127.0.0.1]:51158 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuIQE-0002QV-7E for submit@debbugs.gnu.org; Wed, 22 Jan 2020 11:00:02 -0500 Received: from lists.gnu.org ([209.51.188.17]:35756) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuHDm-0008U7-C4 for submit@debbugs.gnu.org; Wed, 22 Jan 2020 09:43:06 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33381) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iuHDl-0005FV-BP for bug-coreutils@gnu.org; Wed, 22 Jan 2020 09:43:06 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: ** X-Spam-Status: No, score=2.1 required=5.0 tests=BAYES_50,KHOP_HELO_FCRDNS, RDNS_DYNAMIC autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iuHDk-00050T-Fe for bug-coreutils@gnu.org; Wed, 22 Jan 2020 09:43:05 -0500 Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:45894 helo=brightrain.aerifal.cx) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iuHDk-0004zE-As for bug-coreutils@gnu.org; Wed, 22 Jan 2020 09:43:04 -0500 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1iuHDP-0002CP-00; Wed, 22 Jan 2020 14:42:43 +0000 Date: Wed, 22 Jan 2020 09:42:43 -0500 From: Rich Felker To: Florian Weimer Subject: Re: [musl] coreutils cp mishandles error return from lchmod Message-ID: <20200122144243.GZ30412@brightrain.aerifal.cx> References: <20200122141557.GA8157@brightrain.aerifal.cx> <87ftg7k1at.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ftg7k1at.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 216.12.86.13 X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Wed, 22 Jan 2020 11:00:00 -0500 Cc: musl@lists.openwall.com, bug-coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote: > * Rich Felker: > > > coreutils should be opting to use the system-provided lchmod, which is > > safe, and correctly handling error returns (silently treating > > EOPNOTSUPP as success) rather than as hard errors. > > glibc's lchmod always returns ENOSYS (except on Hurd). I don't know how > lchmod is used in coreutils, but I suspect it is not particularly > useful. When preserving permissions (cp -p, archive extraction, etc.), you want lchmod to work correctly just for the purpose of *not* following the link and thereby unwantedly changing the permissions of the link target. But, fchmodat with AT_SYMLINK_NOFOLLOW works just as well and is standard, and that's really what coreutils should be using. Rich From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 11:00:03 2020 Received: (at 39236) by debbugs.gnu.org; 22 Jan 2020 16:00:03 +0000 Received: from localhost ([127.0.0.1]:51160 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuIQE-0002Qd-QK for submit@debbugs.gnu.org; Wed, 22 Jan 2020 11:00:03 -0500 Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:54454 helo=brightrain.aerifal.cx) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuHit-0001II-5S for 39236@debbugs.gnu.org; Wed, 22 Jan 2020 10:15:16 -0500 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1iuHil-0002IE-00; Wed, 22 Jan 2020 15:15:07 +0000 Date: Wed, 22 Jan 2020 10:15:07 -0500 From: Rich Felker To: Florian Weimer Subject: Re: [musl] coreutils cp mishandles error return from lchmod Message-ID: <20200122151507.GB30412@brightrain.aerifal.cx> References: <20200122141557.GA8157@brightrain.aerifal.cx> <87ftg7k1at.fsf@oldenburg2.str.redhat.com> <20200122144243.GZ30412@brightrain.aerifal.cx> <87a76fjzpx.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a76fjzpx.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 0.6 (/) X-Debbugs-Envelope-To: 39236 X-Mailman-Approved-At: Wed, 22 Jan 2020 11:00:00 -0500 Cc: musl@lists.openwall.com, 39236@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.4 (/) On Wed, Jan 22, 2020 at 04:08:26PM +0100, Florian Weimer wrote: > * Rich Felker: > > > On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote: > >> * Rich Felker: > >> > >> > coreutils should be opting to use the system-provided lchmod, which is > >> > safe, and correctly handling error returns (silently treating > >> > EOPNOTSUPP as success) rather than as hard errors. > >> > >> glibc's lchmod always returns ENOSYS (except on Hurd). I don't know how > >> lchmod is used in coreutils, but I suspect it is not particularly > >> useful. > > > > When preserving permissions (cp -p, archive extraction, etc.), you > > want lchmod to work correctly just for the purpose of *not* following > > the link and thereby unwantedly changing the permissions of the link > > target. But, fchmodat with AT_SYMLINK_NOFOLLOW works just as well and > > is standard, and that's really what coreutils should be using. > > 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. Yes, I understood that. I was going into why there should be a real implementation, but didn't make it clear that that was what I was doing. > The reason for this is that the kernel does not provide a suitable > system call to implement this, even though some file systems allow a > mode change for symbolic links. I think we can do better, although I > should note that each time we implement such emulation in userspace, it > comes back to bite us eventually. Emulations in userspace that are approximate, have race conditions, etc. are bad. Ones that are rigorous are good, though. Rich From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 11:08:00 2020 Received: (at 39236) by debbugs.gnu.org; 22 Jan 2020 16:08:00 +0000 Received: from localhost ([127.0.0.1]:51182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuIXw-0002eU-57 for submit@debbugs.gnu.org; Wed, 22 Jan 2020 11:08:00 -0500 Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:54460 helo=brightrain.aerifal.cx) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuIXu-0002eM-Ls for 39236@debbugs.gnu.org; Wed, 22 Jan 2020 11:07:59 -0500 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1iuIXf-0002Ra-00; Wed, 22 Jan 2020 16:07:43 +0000 Date: Wed, 22 Jan 2020 11:07:43 -0500 From: Rich Felker To: Florian Weimer Subject: Re: [musl] coreutils cp mishandles error return from lchmod Message-ID: <20200122160743.GC30412@brightrain.aerifal.cx> References: <20200122141557.GA8157@brightrain.aerifal.cx> <87ftg7k1at.fsf@oldenburg2.str.redhat.com> <20200122144243.GZ30412@brightrain.aerifal.cx> <87a76fjzpx.fsf@oldenburg2.str.redhat.com> <20200122151507.GB30412@brightrain.aerifal.cx> <87zhefik0y.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zhefik0y.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 0.6 (/) X-Debbugs-Envelope-To: 39236 Cc: musl@lists.openwall.com, 39236@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.4 (/) On Wed, Jan 22, 2020 at 04:32:45PM +0100, Florian Weimer wrote: > * Rich Felker: > > > On Wed, Jan 22, 2020 at 04:08:26PM +0100, Florian Weimer wrote: > >> * Rich Felker: > >> > >> > On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote: > >> >> * Rich Felker: > >> >> > >> >> > coreutils should be opting to use the system-provided lchmod, which is > >> >> > safe, and correctly handling error returns (silently treating > >> >> > EOPNOTSUPP as success) rather than as hard errors. > >> >> > >> >> glibc's lchmod always returns ENOSYS (except on Hurd). I don't know how > >> >> lchmod is used in coreutils, but I suspect it is not particularly > >> >> useful. > >> > > >> > When preserving permissions (cp -p, archive extraction, etc.), you > >> > want lchmod to work correctly just for the purpose of *not* following > >> > the link and thereby unwantedly changing the permissions of the link > >> > target. But, fchmodat with AT_SYMLINK_NOFOLLOW works just as well and > >> > is standard, and that's really what coreutils should be using. > >> > >> 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. > > > > Yes, I understood that. I was going into why there should be a real > > implementation, but didn't make it clear that that was what I was > > doing. > > Ah, yes, there should be a real implementation if we can get full > lchmod/AT_SYMLINK_NOFOLLOW behavior on file systems that support it. If > we can't, I'm not sure if there is a point to it. The point is to fail when the target is a symlink, rather than (erroneously and possibly dangerously) applying the chmod to the link target. Actually supporting link modes is useless. It's the "not modifying the target" that's important. > >> The reason for this is that the kernel does not provide a suitable > >> system call to implement this, even though some file systems allow a > >> mode change for symbolic links. I think we can do better, although I > >> should note that each time we implement such emulation in userspace, it > >> comes back to bite us eventually. > > > > Emulations in userspace that are approximate, have race conditions, > > etc. are bad. Ones that are rigorous are good, though. > > Is there a reason for the S_ISLNK check in the musl implementation? > With current kernels, chmod on the proc pseudo-file will not traverse > the symbolic link, but I have yet to check if this has always been the > case. It's explained in the bz you just replied on, https://sourceware.org/bugzilla/show_bug.cgi?id=14578 The point of the S_ISLNK check is to fail out early with the ENOTSUPP, which the caller should treat as "success-like", in the non-racing condition, without the need to open a fd (which may fail with ENFILE/EMFILE) and without the need for /proc to be mounted. Otherwise, a different error will be produced when one of those cases is hit, and the caller will treat it as a real error. Rich From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 11:19:14 2020 Received: (at 39236) by debbugs.gnu.org; 22 Jan 2020 16:19:14 +0000 Received: from localhost ([127.0.0.1]:51204 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuIio-0004wl-Eq for submit@debbugs.gnu.org; Wed, 22 Jan 2020 11:19:14 -0500 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:24421 helo=us-smtp-delivery-1.mimecast.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuIim-0004wd-JR for 39236@debbugs.gnu.org; Wed, 22 Jan 2020 11:19:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579709951; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zeQORNwkm9Y5eAZO0NO+SYMTGlLa/12TJHMX7xt/F84=; b=iiianIymwP5cjBPIevQVx+x9ek26VbtH/3Id4z5JwKNAHzWICNP20F+18ruBAG8GSOz33u XtWRj8Idz5+dYgW/BjMIE5+OKrY2OEY9pbAhcaW92tKUwjI0nfH7NAb7/rJ7ZghkeC4lFv Sbh4BwtTMUTteYq/9G++awXuOFphaBY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-156-pAF230loNzq0cTwbCCBKbQ-1; Wed, 22 Jan 2020 11:19:09 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4DF601005512; Wed, 22 Jan 2020 16:19:08 +0000 (UTC) Received: from oldenburg2.str.redhat.com (dhcp-192-227.str.redhat.com [10.33.192.227]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 690711001B03; Wed, 22 Jan 2020 16:19:07 +0000 (UTC) From: Florian Weimer To: Rich Felker Subject: Re: [musl] coreutils cp mishandles error return from lchmod References: <20200122141557.GA8157@brightrain.aerifal.cx> <87ftg7k1at.fsf@oldenburg2.str.redhat.com> <20200122144243.GZ30412@brightrain.aerifal.cx> <87a76fjzpx.fsf@oldenburg2.str.redhat.com> <20200122151507.GB30412@brightrain.aerifal.cx> <87zhefik0y.fsf@oldenburg2.str.redhat.com> <20200122160743.GC30412@brightrain.aerifal.cx> Date: Wed, 22 Jan 2020 17:19:05 +0100 In-Reply-To: <20200122160743.GC30412@brightrain.aerifal.cx> (Rich Felker's message of "Wed, 22 Jan 2020 11:07:43 -0500") Message-ID: <87v9p3ihvq.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-MC-Unique: pAF230loNzq0cTwbCCBKbQ-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 39236 Cc: musl@lists.openwall.com, 39236@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) * Rich Felker: > On Wed, Jan 22, 2020 at 04:32:45PM +0100, Florian Weimer wrote: >> * Rich Felker: >>=20 >> > On Wed, Jan 22, 2020 at 04:08:26PM +0100, Florian Weimer wrote: >> >> * Rich Felker: >> >>=20 >> >> > On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote: >> >> >> * Rich Felker: >> >> >>=20 >> >> >> > coreutils should be opting to use the system-provided lchmod, wh= ich is >> >> >> > safe, and correctly handling error returns (silently treating >> >> >> > EOPNOTSUPP as success) rather than as hard errors. >> >> >>=20 >> >> >> glibc's lchmod always returns ENOSYS (except on Hurd). I don't kn= ow how >> >> >> lchmod is used in coreutils, but I suspect it is not particularly >> >> >> useful. >> >> > >> >> > When preserving permissions (cp -p, archive extraction, etc.), you >> >> > want lchmod to work correctly just for the purpose of *not* followi= ng >> >> > the link and thereby unwantedly changing the permissions of the lin= k >> >> > target. But, fchmodat with AT_SYMLINK_NOFOLLOW works just as well a= nd >> >> > is standard, and that's really what coreutils should be using. >> >>=20 >> >> I think you misread what I wrote: lchmod *always* returns ENOSYS. Ev= en >> >> if the file is not a symbolic link. Likewise, fchmodat with >> >> AT_SYMLINK_NOFOLLOW *always* returns ENOTSUP. >> > >> > Yes, I understood that. I was going into why there should be a real >> > implementation, but didn't make it clear that that was what I was >> > doing. >>=20 >> Ah, yes, there should be a real implementation if we can get full >> lchmod/AT_SYMLINK_NOFOLLOW behavior on file systems that support it. If >> we can't, I'm not sure if there is a point to it. > > The point is to fail when the target is a symlink, rather than > (erroneously and possibly dangerously) applying the chmod to the link > target. Actually supporting link modes is useless. It's the "not > modifying the target" that's important. The kernel supports it on some file systems, though: $ ls -l /tmp/x l---------. 1 fweimer fweimer 6 Jan 22 15:27 /tmp/x -> /tmp/x Although mode 0 curiously does not prevent readlink calls. > It's explained in the bz you just replied on, > https://sourceware.org/bugzilla/show_bug.cgi?id=3D14578 > > The point of the S_ISLNK check is to fail out early with the ENOTSUPP, > which the caller should treat as "success-like", in the non-racing > condition, without the need to open a fd (which may fail with > ENFILE/EMFILE) and without the need for /proc to be mounted. > Otherwise, a different error will be produced when one of those cases > is hit, and the caller will treat it as a real error. Hmm. The way I read the musl code, the O_PATH descriptor already exists. At this point, you can just chmod the O_PATH descriptor, and have the kernel report EOPNOTSUPP if the file system does not support that. Thanks, Florian From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 12:15:14 2020 Received: (at 39236) by debbugs.gnu.org; 22 Jan 2020 17:15:14 +0000 Received: from localhost ([127.0.0.1]:51241 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuJaz-0008UX-Vi for submit@debbugs.gnu.org; Wed, 22 Jan 2020 12:15:14 -0500 Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:54466 helo=brightrain.aerifal.cx) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuJay-0008UN-1V for 39236@debbugs.gnu.org; Wed, 22 Jan 2020 12:15:12 -0500 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1iuJau-0002bH-00; Wed, 22 Jan 2020 17:15:08 +0000 Date: Wed, 22 Jan 2020 12:15:08 -0500 From: Rich Felker To: Florian Weimer Subject: Re: [musl] coreutils cp mishandles error return from lchmod Message-ID: <20200122171508.GD30412@brightrain.aerifal.cx> References: <20200122141557.GA8157@brightrain.aerifal.cx> <87ftg7k1at.fsf@oldenburg2.str.redhat.com> <20200122144243.GZ30412@brightrain.aerifal.cx> <87a76fjzpx.fsf@oldenburg2.str.redhat.com> <20200122151507.GB30412@brightrain.aerifal.cx> <87zhefik0y.fsf@oldenburg2.str.redhat.com> <20200122160743.GC30412@brightrain.aerifal.cx> <87v9p3ihvq.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87v9p3ihvq.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 0.6 (/) X-Debbugs-Envelope-To: 39236 Cc: musl@lists.openwall.com, 39236@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.4 (/) On Wed, Jan 22, 2020 at 05:19:05PM +0100, Florian Weimer wrote: > * Rich Felker: > > > On Wed, Jan 22, 2020 at 04:32:45PM +0100, Florian Weimer wrote: > >> * Rich Felker: > >> > >> > On Wed, Jan 22, 2020 at 04:08:26PM +0100, Florian Weimer wrote: > >> >> * Rich Felker: > >> >> > >> >> > On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote: > >> >> >> * Rich Felker: > >> >> >> > >> >> >> > coreutils should be opting to use the system-provided lchmod, which is > >> >> >> > safe, and correctly handling error returns (silently treating > >> >> >> > EOPNOTSUPP as success) rather than as hard errors. > >> >> >> > >> >> >> glibc's lchmod always returns ENOSYS (except on Hurd). I don't know how > >> >> >> lchmod is used in coreutils, but I suspect it is not particularly > >> >> >> useful. > >> >> > > >> >> > When preserving permissions (cp -p, archive extraction, etc.), you > >> >> > want lchmod to work correctly just for the purpose of *not* following > >> >> > the link and thereby unwantedly changing the permissions of the link > >> >> > target. But, fchmodat with AT_SYMLINK_NOFOLLOW works just as well and > >> >> > is standard, and that's really what coreutils should be using. > >> >> > >> >> 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. > >> > > >> > Yes, I understood that. I was going into why there should be a real > >> > implementation, but didn't make it clear that that was what I was > >> > doing. > >> > >> Ah, yes, there should be a real implementation if we can get full > >> lchmod/AT_SYMLINK_NOFOLLOW behavior on file systems that support it. If > >> we can't, I'm not sure if there is a point to it. > > > > The point is to fail when the target is a symlink, rather than > > (erroneously and possibly dangerously) applying the chmod to the link > > target. Actually supporting link modes is useless. It's the "not > > modifying the target" that's important. > > The kernel supports it on some file systems, though: > > $ ls -l /tmp/x > l---------. 1 fweimer fweimer 6 Jan 22 15:27 /tmp/x -> /tmp/x > > Although mode 0 curiously does not prevent readlink calls. > > > It's explained in the bz you just replied on, > > https://sourceware.org/bugzilla/show_bug.cgi?id=14578 > > > > The point of the S_ISLNK check is to fail out early with the ENOTSUPP, > > which the caller should treat as "success-like", in the non-racing > > condition, without the need to open a fd (which may fail with > > ENFILE/EMFILE) and without the need for /proc to be mounted. > > Otherwise, a different error will be produced when one of those cases > > is hit, and the caller will treat it as a real error. > > Hmm. The way I read the musl code, the O_PATH descriptor already > exists. At this point, you can just chmod the O_PATH descriptor, and > have the kernel report EOPNOTSUPP if the file system does not support > that. Oh, you mean the second one after it's already open? Maybe that's ok. I was concerned it might follow the link and chmod the target at that point. I thought you were asking about the ealier check before the O_PATH open. Rich From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 15:48:25 2020 Received: (at 39236) by debbugs.gnu.org; 22 Jan 2020 20:48:25 +0000 Received: from localhost ([127.0.0.1]:51420 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuMvJ-0001If-G9 for submit@debbugs.gnu.org; Wed, 22 Jan 2020 15:48:25 -0500 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:57740 helo=us-smtp-delivery-1.mimecast.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuMvH-0001IX-UG for 39236@debbugs.gnu.org; Wed, 22 Jan 2020 15:48:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579726102; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=r6QXS3pEgJQKibNLyQjvdVkXPG74wJboBJopRAUSjv0=; b=HdGRQiZL2JgFYPSmPOfKTmJO/WiN15UsmstAj7IFZcxNnUZNwvXZMoQr1v4tNB402NdHja ViDE3Ywd2TjIW1AJE1hpU2paSL0y6inyRXiDd2IQ9KZwdWylTI7oh6kWCI9R7dRW4heqMP b0/0YW/T5uYI1Lpg1+qm/ZQXTcHxTXo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-160-ltK9dAjQObmVb1vSVETkrQ-1; Wed, 22 Jan 2020 15:48:18 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AB93B800D41; Wed, 22 Jan 2020 20:48:17 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-116-35.ams2.redhat.com [10.36.116.35]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8D61360C81; Wed, 22 Jan 2020 20:48:16 +0000 (UTC) From: Florian Weimer To: Rich Felker Subject: Re: [musl] coreutils cp mishandles error return from lchmod References: <20200122141557.GA8157@brightrain.aerifal.cx> <87ftg7k1at.fsf@oldenburg2.str.redhat.com> <20200122144243.GZ30412@brightrain.aerifal.cx> <87a76fjzpx.fsf@oldenburg2.str.redhat.com> <20200122151507.GB30412@brightrain.aerifal.cx> <87zhefik0y.fsf@oldenburg2.str.redhat.com> <20200122160743.GC30412@brightrain.aerifal.cx> <87v9p3ihvq.fsf@oldenburg2.str.redhat.com> <20200122171508.GD30412@brightrain.aerifal.cx> Date: Wed, 22 Jan 2020 21:48:14 +0100 In-Reply-To: <20200122171508.GD30412@brightrain.aerifal.cx> (Rich Felker's message of "Wed, 22 Jan 2020 12:15:08 -0500") Message-ID: <87zheffca9.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-MC-Unique: ltK9dAjQObmVb1vSVETkrQ-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 39236 Cc: musl@lists.openwall.com, 39236@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) * Rich Felker: >> Hmm. The way I read the musl code, the O_PATH descriptor already >> exists. At this point, you can just chmod the O_PATH descriptor, and >> have the kernel report EOPNOTSUPP if the file system does not support >> that. > > Oh, you mean the second one after it's already open? Maybe that's ok. Yes, that's what I meant. > I was concerned it might follow the link and chmod the target at that > point. In my tests, it works. I think it's also documented behavior for chown on these pseudo-files. I also verified that closing an O_PATH descriptor does not release POSIX advisory locks for the same file. But I'm wondering if there's still something we are missing. Thanks, Florian From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 15:56:11 2020 Received: (at 39236) by debbugs.gnu.org; 22 Jan 2020 20:56:11 +0000 Received: from localhost ([127.0.0.1]:51428 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuN2p-0001UF-H7 for submit@debbugs.gnu.org; Wed, 22 Jan 2020 15:56:11 -0500 Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:54478 helo=brightrain.aerifal.cx) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuN2n-0001U6-Jn for 39236@debbugs.gnu.org; Wed, 22 Jan 2020 15:56:10 -0500 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1iuN2j-0003Gk-00; Wed, 22 Jan 2020 20:56:05 +0000 Date: Wed, 22 Jan 2020 15:56:05 -0500 From: Rich Felker To: Florian Weimer Subject: Re: [musl] coreutils cp mishandles error return from lchmod Message-ID: <20200122205605.GF30412@brightrain.aerifal.cx> References: <20200122141557.GA8157@brightrain.aerifal.cx> <87ftg7k1at.fsf@oldenburg2.str.redhat.com> <20200122144243.GZ30412@brightrain.aerifal.cx> <87a76fjzpx.fsf@oldenburg2.str.redhat.com> <20200122151507.GB30412@brightrain.aerifal.cx> <87zhefik0y.fsf@oldenburg2.str.redhat.com> <20200122160743.GC30412@brightrain.aerifal.cx> <87v9p3ihvq.fsf@oldenburg2.str.redhat.com> <20200122171508.GD30412@brightrain.aerifal.cx> <87zheffca9.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zheffca9.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 0.6 (/) X-Debbugs-Envelope-To: 39236 Cc: musl@lists.openwall.com, 39236@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.4 (/) On Wed, Jan 22, 2020 at 09:48:14PM +0100, Florian Weimer wrote: > * Rich Felker: > > >> Hmm. The way I read the musl code, the O_PATH descriptor already > >> exists. At this point, you can just chmod the O_PATH descriptor, and > >> have the kernel report EOPNOTSUPP if the file system does not support > >> that. > > > > Oh, you mean the second one after it's already open? Maybe that's ok. > > Yes, that's what I meant. > > > I was concerned it might follow the link and chmod the target at that > > point. > > In my tests, it works. I think it's also documented behavior for chown > on these pseudo-files. Do you know where we might find that documentation? > I also verified that closing an O_PATH descriptor does not release POSIX > advisory locks for the same file. But I'm wondering if there's still > something we are missing. Thanks, I hadn't thought to check that, but wouldn't have expected it to be a problem since O_PATH is not actually open to the file. Rich From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 16:06:05 2020 Received: (at 39236) by debbugs.gnu.org; 22 Jan 2020 21:06:05 +0000 Received: from localhost ([127.0.0.1]:51440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuNCP-0001kQ-0O for submit@debbugs.gnu.org; Wed, 22 Jan 2020 16:06:05 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:25751 helo=us-smtp-1.mimecast.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuNCL-0001jz-G3 for 39236@debbugs.gnu.org; Wed, 22 Jan 2020 16:06:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579727160; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Hpb/UwdCusv20drt+5P68lEYQUMf17EZTylexz3emeA=; b=hOLlcyzYeIaQS2dDJ0tZMcq0wPIpVrNklhqlrThQjDFxwNe0KX92V8PLSL7gv7fJAvjbMc 2KiRaYVZFQF/5LVKP9T0MVyuegm2hN1L1YXgJbOmiWPiZAKOSSWGt3xvl9tILIo5RTg4sZ jn/9p6S8aWecZQOitOzMTvw8/XJ391o= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-352-fVaf8RheNLC2YOth5onh_g-1; Wed, 22 Jan 2020 16:05:57 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 064BD8017CC; Wed, 22 Jan 2020 21:05:56 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-116-35.ams2.redhat.com [10.36.116.35]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D69E47C35A; Wed, 22 Jan 2020 21:05:54 +0000 (UTC) From: Florian Weimer To: Rich Felker Subject: Re: [musl] coreutils cp mishandles error return from lchmod References: <20200122141557.GA8157@brightrain.aerifal.cx> <87ftg7k1at.fsf@oldenburg2.str.redhat.com> <20200122144243.GZ30412@brightrain.aerifal.cx> <87a76fjzpx.fsf@oldenburg2.str.redhat.com> <20200122151507.GB30412@brightrain.aerifal.cx> <87zhefik0y.fsf@oldenburg2.str.redhat.com> <20200122160743.GC30412@brightrain.aerifal.cx> <87v9p3ihvq.fsf@oldenburg2.str.redhat.com> <20200122171508.GD30412@brightrain.aerifal.cx> <87zheffca9.fsf@oldenburg2.str.redhat.com> <20200122205605.GF30412@brightrain.aerifal.cx> Date: Wed, 22 Jan 2020 22:05:52 +0100 In-Reply-To: <20200122205605.GF30412@brightrain.aerifal.cx> (Rich Felker's message of "Wed, 22 Jan 2020 15:56:05 -0500") Message-ID: <87v9p3fbgv.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-MC-Unique: fVaf8RheNLC2YOth5onh_g-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 39236 Cc: musl@lists.openwall.com, 39236@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) * Rich Felker: > On Wed, Jan 22, 2020 at 09:48:14PM +0100, Florian Weimer wrote: >> * Rich Felker: >>=20 >> >> Hmm. The way I read the musl code, the O_PATH descriptor already >> >> exists. At this point, you can just chmod the O_PATH descriptor, and >> >> have the kernel report EOPNOTSUPP if the file system does not support >> >> that. >> > >> > Oh, you mean the second one after it's already open? Maybe that's ok. >>=20 >> Yes, that's what I meant. >>=20 >> > I was concerned it might follow the link and chmod the target at that >> > point. >>=20 >> In my tests, it works. I think it's also documented behavior for chown >> on these pseudo-files. > > Do you know where we might find that documentation? Ugh. I'm probably misremembering. It may have been a rejection of patch to implement another f*at system call with AT_EMPTY_PATH support. (I did find your 2013 message describing the chmod and chown behavior.) Thanks, Florian From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 16:56:07 2020 Received: (at 39236) by debbugs.gnu.org; 22 Jan 2020 21:56:07 +0000 Received: from localhost ([127.0.0.1]:51472 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuNyp-0002vs-8Q for submit@debbugs.gnu.org; Wed, 22 Jan 2020 16:56:07 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:58268) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuNyn-0002vK-42 for 39236@debbugs.gnu.org; Wed, 22 Jan 2020 16:56:06 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 611C8160081; Wed, 22 Jan 2020 13:55:58 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 3N95TrnnwWKm; Wed, 22 Jan 2020 13:55:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9EDD916008F; Wed, 22 Jan 2020 13:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aYl-2iRFTf_6; Wed, 22 Jan 2020 13:55:57 -0800 (PST) Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 802BD160081; Wed, 22 Jan 2020 13:55:57 -0800 (PST) Subject: Re: bug#39236: [musl] coreutils cp mishandles error return from lchmod To: Florian Weimer , Rich Felker 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 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 39236 Cc: musl@lists.openwall.com, 39236@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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.) From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 17:05:46 2020 Received: (at 39236) by debbugs.gnu.org; 22 Jan 2020 22:05:47 +0000 Received: from localhost ([127.0.0.1]:51478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuO8A-0003Ab-6b for submit@debbugs.gnu.org; Wed, 22 Jan 2020 17:05:46 -0500 Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:54492 helo=brightrain.aerifal.cx) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iuO85-0003AP-1A for 39236@debbugs.gnu.org; Wed, 22 Jan 2020 17:05:45 -0500 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1iuO7f-0003QN-00; Wed, 22 Jan 2020 22:05:15 +0000 Date: Wed, 22 Jan 2020 17:05:15 -0500 From: Rich Felker To: Paul Eggert Subject: Re: bug#39236: [musl] coreutils cp mishandles error return from lchmod Message-ID: <20200122220515.GH30412@brightrain.aerifal.cx> References: <20200122141557.GA8157@brightrain.aerifal.cx> <87ftg7k1at.fsf@oldenburg2.str.redhat.com> <20200122144243.GZ30412@brightrain.aerifal.cx> <87a76fjzpx.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 0.6 (/) X-Debbugs-Envelope-To: 39236 Cc: Florian Weimer , musl@lists.openwall.com, 39236@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.4 (/) On Wed, Jan 22, 2020 at 01:55:57PM -0800, Paul Eggert wrote: > 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? I think you're confusing fchmodat with fstatat. The Linux fchmodat syscall lacks a flags argument and thus doesn't suffice to implement fchmodat. The fstatat syscall does work. > 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? I think fchmod historically did not work on O_PATH file descriptors, which is why musl is using chmod on the procfs magic symlink. However, fchmodat might work too with an empty pathname; I'm not sure. I think these fixes are better encapsulated as a replacement for missing/broken fchmodat, rather than putting the logic in individual utilities or coreutils-specific library code. Also, note that if you want to skip checking stat to make sure you didn't open a symlink with O_PATH, that depends on confirming Florian's claim that the kernel documents it will not follow the symlink. > 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.) I think we're approaching a consensus that glibc should fix this too, so then it would just be gnulib matching the fix. Rich From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 07 19:38:10 2020 Received: (at 39236) by debbugs.gnu.org; 8 Feb 2020 00:38:10 +0000 Received: from localhost ([127.0.0.1]:50490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j0E8P-0007Ld-Ih for submit@debbugs.gnu.org; Fri, 07 Feb 2020 19:38:10 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:50628) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j0E8M-0007L7-IQ for 39236@debbugs.gnu.org; Fri, 07 Feb 2020 19:38:08 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A9C64160081; Fri, 7 Feb 2020 16:37:59 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id hVVm3ueDm4fX; Fri, 7 Feb 2020 16:37:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 33270160087; Fri, 7 Feb 2020 16:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 43UU7RLUtZYF; Fri, 7 Feb 2020 16:37:57 -0800 (PST) Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 099C0160081; Fri, 7 Feb 2020 16:37:57 -0800 (PST) Subject: Re: bug#39236: [musl] coreutils cp mishandles error return from lchmod To: Rich Felker References: <20200122141557.GA8157@brightrain.aerifal.cx> <87ftg7k1at.fsf@oldenburg2.str.redhat.com> <20200122144243.GZ30412@brightrain.aerifal.cx> <87a76fjzpx.fsf@oldenburg2.str.redhat.com> <20200122220515.GH30412@brightrain.aerifal.cx> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <38d0e03d-4718-8085-4474-981fdef9b4b8@cs.ucla.edu> Date: Fri, 7 Feb 2020 16:37:56 -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: <20200122220515.GH30412@brightrain.aerifal.cx> Content-Type: multipart/mixed; boundary="------------CAC4BA9170C59056E7CA3C6D" Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 39236 Cc: Florian Weimer , Gnulib bugs , musl@lists.openwall.com, 39236@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------CAC4BA9170C59056E7CA3C6D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 1/22/20 2:05 PM, Rich Felker wrote: > I think we're approaching a consensus that glibc should fix this too, > so then it would just be gnulib matching the fix. I installed the attached patch to Gnulib in preparation for the upcoming glibc fix. The patch causes fchmodat with AT_SYMLINK_NOFOLLOW to work on non-symlinks, and similarly for lchmod on non-symlinks. The idea is to avoid this sort of problem in the future, and to let Coreutils etc. work on older platforms as if glibc 2.32 (or whatever) is already in place. --------------CAC4BA9170C59056E7CA3C6D Content-Type: text/x-patch; charset=UTF-8; name="0001-fchmodat-AT_SYMLINK_NOFOLLOW-fix-for-non-symlinks.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-fchmodat-AT_SYMLINK_NOFOLLOW-fix-for-non-symlinks.patch" >From b16a04394121e7396569a13161dba02c6752b19f Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 7 Feb 2020 16:34:12 -0800 Subject: [PATCH] fchmodat: AT_SYMLINK_NOFOLLOW fix for non-symlinks Fix lchmod, and fchmodat with AT_SYMLINK_NOFOLLOW, so that they act like chmod on non-symlinks. * NEWS: * doc/glibc-functions/lchmod.texi (lchmod): * doc/posix-functions/fchmodat.texi (fchmodat): Mention this. * lib/fchmodat.c: Define __need_system_sys_stat_h before including config.h, and undef it after including sys/stat.h the first time. Include fcntl.h, stdio.h, unistd.h, intprops.h, and include sys/stat.h a second time after defining orig_fchmodat. (orig_fchmodat) [HAVE_FCHMODAT]: New function. (fchmodat) [HAVE_FCHMODAT]: Work around the AT_SYMLINK_NOFOLLOW bug. * lib/lchmod.c: New file. * lib/sys_stat.in.h (fchmodat, lchmod): Support replacing these functions. * m4/fchmodat.m4 (gl_FUNC_FCHMODAT): If fchmodat exists, test that AT_SYMLINK_NOFOLLOW works on non-symlinks. * m4/lchmod.m4 (gl_FUNC_LCHMOD): Check for lstat. Test that lchmod works on non-symlinks. * m4/sys_stat_h.m4 (gl_SYS_STAT_H_DEFAULTS): Default REPLACE_FCHMODAT and REPLACE_LCHMOD to 0. * modules/fchmodat (Depends-on): Add fstatat, intprops, lchmod, unistd. (Depends-on, configure.ac): Check REPLACE_FCHMODAT too. * modules/lchmod (Files): Add lib/lchmod.c. (Depends-on): Add errno, fcntl-h, fchmodat, intprops, lstat, unistd. (configure.ac): Compile lchmod.c if needed. (lib_SOURCES): Add lchmod.c. * modules/sys_stat (sys/stat.h): Substitute REPLACE_FCHMODAT and REPLACE_LCHMOD. * tests/test-fchmodat.c: Include fcntl.h, sys/stat.h. (main): Test fchmodat with AT_SYMLINK_NOFOLLOW on non-symlinks. --- ChangeLog | 35 ++++++++++++ NEWS | 7 +++ doc/glibc-functions/lchmod.texi | 4 ++ doc/posix-functions/fchmodat.texi | 11 ++-- lib/fchmodat.c | 89 +++++++++++++++++++++++++------ lib/lchmod.c | 72 +++++++++++++++++++++++++ lib/sys_stat.in.h | 41 +++++++------- m4/fchmodat.m4 | 48 ++++++++++++++++- m4/lchmod.m4 | 52 ++++++++++++++++-- m4/sys_stat_h.m4 | 4 +- modules/fchmodat | 10 ++-- modules/lchmod | 13 ++++- modules/sys_stat | 2 + tests/test-fchmodat.c | 10 ++++ 14 files changed, 348 insertions(+), 50 deletions(-) create mode 100644 lib/lchmod.c diff --git a/ChangeLog b/ChangeLog index 99e0c2e9e..71dcaba6c 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,38 @@ +2020-02-07 Paul Eggert + + fchmodat: AT_SYMLINK_NOFOLLOW fix for non-symlinks + Fix lchmod, and fchmodat with AT_SYMLINK_NOFOLLOW, so that + they act like chmod on non-symlinks. + * NEWS: + * doc/glibc-functions/lchmod.texi (lchmod): + * doc/posix-functions/fchmodat.texi (fchmodat): + Mention this. + * lib/fchmodat.c: Define __need_system_sys_stat_h before including + config.h, and undef it after including sys/stat.h the first time. + Include fcntl.h, stdio.h, unistd.h, intprops.h, and include + sys/stat.h a second time after defining orig_fchmodat. + (orig_fchmodat) [HAVE_FCHMODAT]: New function. + (fchmodat) [HAVE_FCHMODAT]: Work around the AT_SYMLINK_NOFOLLOW bug. + * lib/lchmod.c: New file. + * lib/sys_stat.in.h (fchmodat, lchmod): + Support replacing these functions. + * m4/fchmodat.m4 (gl_FUNC_FCHMODAT): If fchmodat exists, + test that AT_SYMLINK_NOFOLLOW works on non-symlinks. + * m4/lchmod.m4 (gl_FUNC_LCHMOD): Check for lstat. + Test that lchmod works on non-symlinks. + * m4/sys_stat_h.m4 (gl_SYS_STAT_H_DEFAULTS): + Default REPLACE_FCHMODAT and REPLACE_LCHMOD to 0. + * modules/fchmodat (Depends-on): Add fstatat, intprops, lchmod, unistd. + (Depends-on, configure.ac): Check REPLACE_FCHMODAT too. + * modules/lchmod (Files): Add lib/lchmod.c. + (Depends-on): Add errno, fcntl-h, fchmodat, intprops, lstat, unistd. + (configure.ac): Compile lchmod.c if needed. + (lib_SOURCES): Add lchmod.c. + * modules/sys_stat (sys/stat.h): Substitute REPLACE_FCHMODAT + and REPLACE_LCHMOD. + * tests/test-fchmodat.c: Include fcntl.h, sys/stat.h. + (main): Test fchmodat with AT_SYMLINK_NOFOLLOW on non-symlinks. + 2020-02-05 Marc Dionne (tiny change) mountlist: Consider AFS filesystems as remote diff --git a/NEWS b/NEWS index dc5cc71f9..bc81dfc28 100644 --- a/NEWS +++ b/NEWS @@ -58,6 +58,13 @@ User visible incompatible changes Date Modules Changes +2020-02-07 fchmodat When applied to non-symlinks, these now act like + lchmod chmod (the BSD behavior, which POSIX requires for + fchmodat + AT_SYMLINK_NOFOLLOW), instead of failing + (the GNU/Linux behavior through glibc 2.31). + Future versions of GNU/Linux are planned to act as + per POSIX and BSD. + 2020-01-15 gc-pbkdf2-sha1 This module is deprecated. Use gc-pbkdf2 instead. 2019-12-12 dfa Its API now uses ptrdiff_t instead of size_t. diff --git a/doc/glibc-functions/lchmod.texi b/doc/glibc-functions/lchmod.texi index aea782dc2..6cc48b453 100644 --- a/doc/glibc-functions/lchmod.texi +++ b/doc/glibc-functions/lchmod.texi @@ -9,6 +9,10 @@ Portability problems fixed by Gnulib: @item This function is missing on some platforms: OpenBSD 3.8, Minix 3.1.8, AIX 5.1, IRIX 6.5, Solaris 11.4, Cygwin, mingw, MSVC 14, Android 9.0. +@item +This function always fails with @code{errno} set to @code{ENOSYS}, +even when the file is not a symbolic link: +GNU/Linux with glibc 2.31. @end itemize Portability problems not fixed by Gnulib: diff --git a/doc/posix-functions/fchmodat.texi b/doc/posix-functions/fchmodat.texi index 6add5ba89..4d190310e 100644 --- a/doc/posix-functions/fchmodat.texi +++ b/doc/posix-functions/fchmodat.texi @@ -9,6 +9,11 @@ Gnulib module: fchmodat Portability problems fixed by Gnulib: @itemize @item +When given the @code{AT_SYMLINK_NOFOLLOW} flag, +this function fails with @code{errno} set to @code{ENOTSUP}, +even when the file is not a symbolic link: +GNU/Linux and Cygwin with glibc 2.31. +@item This function is missing on some platforms: glibc 2.3.6, Mac OS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1, HP-UX 11, IRIX 6.5, Solaris 10, Cygwin 1.5.x, mingw, MSVC 14. @@ -19,9 +24,5 @@ Portability problems not fixed by Gnulib: @itemize @item Some platforms do not allow changing the access bits on symbolic -links. POSIX states that @code{fchmodat(@dots{},AT_SYMLINK_NOFOLLOW)} -may fail with @code{EOPNOTSUPP} when called on a symlink, but some -platforms, as well as the gnulib replacement, fail for any use of -AT_SYMLINK_NOFOLLOW even if the target was not a symlink: -glibc, Cygwin. +links. @end itemize diff --git a/lib/fchmodat.c b/lib/fchmodat.c index 0d4891b3e..c6b8ef768 100644 --- a/lib/fchmodat.c +++ b/lib/fchmodat.c @@ -16,29 +16,42 @@ /* written by Jim Meyering */ +/* If the user's config.h happens to include , let it include only + the system's here, so that orig_fchmodat doesn't recurse to + rpl_fchmodat. */ +#define __need_system_sys_stat_h #include /* Specification. */ #include +#undef __need_system_sys_stat_h #include +#include +#include #include +#include -#ifndef HAVE_LCHMOD -/* Use a different name, to avoid conflicting with any - system-supplied declaration. */ -# undef lchmod -# define lchmod lchmod_rpl +#if HAVE_FCHMODAT static int -lchmod (char const *f _GL_UNUSED, mode_t m _GL_UNUSED) +orig_fchmodat (int dir, char const *file, mode_t mode, int flags) { - errno = ENOSYS; - return -1; + return fchmodat (dir, file, mode, flags); } #endif -/* Solaris 10 has no function like this. - Invoke chmod or lchmod on file, FILE, using mode MODE, in the directory +#ifdef __osf__ +/* Write "sys/stat.h" here, not , otherwise OSF/1 5.1 DTK cc + eliminates this include because of the preliminary #include + above. */ +# include "sys/stat.h" +#else +# include +#endif + +#include + +/* Invoke chmod or lchmod on FILE, using mode MODE, in the directory open on descriptor FD. If possible, do it without changing the working directory. Otherwise, resort to using save_cwd/fchdir, then (chmod|lchmod)/restore_cwd. If either the save_cwd or the @@ -46,10 +59,52 @@ lchmod (char const *f _GL_UNUSED, mode_t m _GL_UNUSED) Note that an attempt to use a FLAG value of AT_SYMLINK_NOFOLLOW on a system without lchmod support causes this function to fail. */ -#define AT_FUNC_NAME fchmodat -#define AT_FUNC_F1 lchmod -#define AT_FUNC_F2 chmod -#define AT_FUNC_USE_F1_COND AT_SYMLINK_NOFOLLOW -#define AT_FUNC_POST_FILE_PARAM_DECLS , mode_t mode, int flag -#define AT_FUNC_POST_FILE_ARGS , mode -#include "at-func.c" +#if HAVE_FCHMODAT +int +fchmodat (int dir, char const *file, mode_t mode, int flags) +{ + if (flags & AT_SYMLINK_NOFOLLOW) + { +# ifdef O_PATH + int fd = openat (dir, file, O_PATH | O_NOFOLLOW | O_CLOEXEC); + if (fd < 0) + return fd; + static char const fmt[] = "/proc/self/fd/%d"; + char buf[sizeof fmt - sizeof "%d" + INT_BUFSIZE_BOUND (int)]; + sprintf (buf, fmt, fd); + int chmod_result = chmod (buf, mode); + int chmod_errno = errno; + close (fd); + if (chmod_result == 0) + return chmod_result; + if (chmod_errno != ENOENT) + { + errno = chmod_errno; + return chmod_result; + } + /* /proc is not mounted; fall back on racy implementation. */ +# endif + + struct stat st; + int fstatat_result = fstatat (dir, file, &st, AT_SYMLINK_NOFOLLOW); + if (fstatat_result != 0) + return fstatat_result; + if (S_ISLNK (st.st_mode)) + { + errno = EOPNOTSUPP; + return -1; + } + flags &= ~AT_SYMLINK_NOFOLLOW; + } + + return orig_fchmodat (dir, file, mode, flags); +} +#else +# define AT_FUNC_NAME fchmodat +# define AT_FUNC_F1 lchmod +# define AT_FUNC_F2 chmod +# define AT_FUNC_USE_F1_COND AT_SYMLINK_NOFOLLOW +# define AT_FUNC_POST_FILE_PARAM_DECLS , mode_t mode, int flag +# define AT_FUNC_POST_FILE_ARGS , mode +# include "at-func.c" +#endif diff --git a/lib/lchmod.c b/lib/lchmod.c new file mode 100644 index 000000000..cc260ce4d --- /dev/null +++ b/lib/lchmod.c @@ -0,0 +1,72 @@ +/* Implement lchmod on platforms where it does not work correctly. + + Copyright 2020 Free Software Foundation, Inc. + + This program is free software: you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +/* written by Paul Eggert */ + +#include + +#include + +#include +#include +#include +#include + +#include + +/* Work like lchmod, except when FILE is a symbolic link. + In that case, set errno to EOPNOTSUPP and return -1. */ + +int +lchmod (char const *file, mode_t mode) +{ +#if HAVE_FCHMODAT + return fchmodat (AT_FDCWD, file, mode, AT_SYMLINK_NOFOLLOW); +#elif defined O_PATH && defined AT_FDCWD + int fd = openat (AT_FDCWD, file, O_PATH | O_NOFOLLOW | O_CLOEXEC); + if (fd < 0) + return fd; + static char const fmt[] = "/proc/self/fd/%d"; + char buf[sizeof fmt - sizeof "%d" + INT_BUFSIZE_BOUND (int)]; + sprintf (buf, fmt, fd); + int chmod_result = chmod (buf, mode); + int chmod_errno = errno; + close (fd); + if (chmod_result == 0) + return chmod_result; + if (chmod_errno != ENOENT) + { + errno = chmod_errno; + return chmod_result; + } + /* /proc is not mounted; fall back on racy implementation. */ +#endif + +#if HAVE_LSTAT + struct stat st; + int lstat_result = lstat (file, &st); + if (lstat_result != 0) + return lstat_result; + if (S_ISLNK (st.st_mode)) + { + errno = EOPNOTSUPP; + return -1; + } +#endif + + return chmod (file, mode); +} diff --git a/lib/sys_stat.in.h b/lib/sys_stat.in.h index 5c891e7b8..4f9eb5976 100644 --- a/lib/sys_stat.in.h +++ b/lib/sys_stat.in.h @@ -392,13 +392,25 @@ struct stat #if @GNULIB_FCHMODAT@ -# if !@HAVE_FCHMODAT@ +# if @REPLACE_FCHMODAT@ +# if !(defined __cplusplus && defined GNULIB_NAMESPACE) +# undef fchmodat +# define fchmodat rpl_fchmodat +# endif +_GL_FUNCDECL_RPL (fchmodat, int, + (int fd, char const *file, mode_t mode, int flag) + _GL_ARG_NONNULL ((2))); +_GL_CXXALIAS_RPL (fchmodat, int, + (int fd, char const *file, mode_t mode, int flag)); +# else +# if !@HAVE_FCHMODAT@ _GL_FUNCDECL_SYS (fchmodat, int, (int fd, char const *file, mode_t mode, int flag) _GL_ARG_NONNULL ((2))); -# endif +# endif _GL_CXXALIAS_SYS (fchmodat, int, (int fd, char const *file, mode_t mode, int flag)); +# endif _GL_CXXALIASWARN (fchmodat); #elif defined GNULIB_POSIXCHECK # undef fchmodat @@ -502,31 +514,24 @@ _GL_WARN_ON_USE (futimens, "futimens is not portable - " #if @GNULIB_LCHMOD@ /* Change the mode of FILENAME to MODE, without dereferencing it if FILENAME denotes a symbolic link. */ -# if !@HAVE_LCHMOD@ -/* The lchmod replacement follows symbolic links. Callers should take - this into account; lchmod should be applied only to arguments that - are known to not be symbolic links. On hosts that lack lchmod, - this can lead to race conditions between the check and the - invocation of lchmod, but we know of no workarounds that are - reliable in general. You might try requesting support for lchmod - from your operating system supplier. */ +# if @REPLACE_LCHMOD@ # if !(defined __cplusplus && defined GNULIB_NAMESPACE) -# define lchmod chmod +# undef lchmod +# define lchmod rpl_lchmod # endif -/* Need to cast, because on mingw, the second parameter of chmod is - int mode. */ -_GL_CXXALIAS_RPL_CAST_1 (lchmod, chmod, int, - (const char *filename, mode_t mode)); +_GL_FUNCDECL_RPL (lchmod, int, + (char const *filename, mode_t mode) + _GL_ARG_NONNULL ((1))); +_GL_CXXALIAS_RPL (lchmod, int, + (char const *filename, mode_t mode)); # else -# if 0 /* assume already declared */ +# if !@HAVE_LCHMOD@ _GL_FUNCDECL_SYS (lchmod, int, (const char *filename, mode_t mode) _GL_ARG_NONNULL ((1))); # endif _GL_CXXALIAS_SYS (lchmod, int, (const char *filename, mode_t mode)); # endif -# if @HAVE_LCHMOD@ _GL_CXXALIASWARN (lchmod); -# endif #elif defined GNULIB_POSIXCHECK # undef lchmod # if HAVE_RAW_DECL_LCHMOD diff --git a/m4/fchmodat.m4 b/m4/fchmodat.m4 index 460a4dc17..8195ef668 100644 --- a/m4/fchmodat.m4 +++ b/m4/fchmodat.m4 @@ -1,4 +1,4 @@ -# fchmodat.m4 serial 1 +# fchmodat.m4 serial 2 dnl Copyright (C) 2004-2020 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -13,5 +13,51 @@ AC_DEFUN([gl_FUNC_FCHMODAT], AC_CHECK_FUNCS_ONCE([fchmodat lchmod]) if test $ac_cv_func_fchmodat != yes; then HAVE_FCHMODAT=0 + else + AC_CACHE_CHECK( + [whether fchmodat+AT_SYMLINK_NOFOLLOW works on non-symlinks], + [gl_cv_func_fchmodat_works], + [AC_RUN_IFELSE( + [AC_LANG_PROGRAM( + [ + AC_INCLUDES_DEFAULT[ + #include + #ifndef S_IRUSR + #define S_IRUSR 0400 + #endif + #ifndef S_IWUSR + #define S_IWUSR 0200 + #endif + #ifndef S_IRWXU + #define S_IRWXU 0700 + #endif + #ifndef S_IRWXG + #define S_IRWXG 0070 + #endif + #ifndef S_IRWXO + #define S_IRWXO 0007 + #endif + ]], + [[ + int permissive = S_IRWXU | S_IRWXG | S_IRWXO; + int desired = S_IRUSR | S_IWUSR; + static char const f[] = "conftest.fchmodat"; + struct stat st; + if (creat (f, permissive) < 0) + return 1; + if (fchmodat (AT_FDCWD, f, desired, AT_SYMLINK_NOFOLLOW) != 0) + return 1; + if (stat (f, &st) != 0) + return 1; + return ! ((st.st_mode & permissive) == desired); + ]])], + [gl_cv_func_fchmodat_works=yes], + [gl_cv_func_fchmodat_works=no], + [gl_cv_func_fchmodat_works=$gl_cross_guess_normal]) + rm -f conftest.fchmodat]) + case $gl_cv_func_fchmodat_works in + *yes) ;; + *) REPLACE_FCHMODAT=1;; + esac fi ]) diff --git a/m4/lchmod.m4 b/m4/lchmod.m4 index eeca7ac20..68dab7a4a 100644 --- a/m4/lchmod.m4 +++ b/m4/lchmod.m4 @@ -1,4 +1,4 @@ -#serial 3 +#serial 4 dnl Copyright (C) 2005-2006, 2008-2020 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation @@ -6,7 +6,7 @@ dnl gives unlimited permission to copy and/or distribute it, dnl with or without modifications, as long as this notice is preserved. dnl From Paul Eggert. -dnl Provide a replacement for lchmod on hosts that lack it. +dnl Provide a replacement for lchmod on hosts that lack a working version. AC_DEFUN([gl_FUNC_LCHMOD], [ @@ -15,8 +15,52 @@ AC_DEFUN([gl_FUNC_LCHMOD], dnl Persuade glibc to declare lchmod(). AC_REQUIRE([AC_USE_SYSTEM_EXTENSIONS]) - AC_CHECK_FUNCS_ONCE([lchmod]) - if test $ac_cv_func_lchmod = no; then + AC_CHECK_FUNCS_ONCE([fchmodat lchmod lstat]) + if test "$ac_cv_func_lchmod" = no; then HAVE_LCHMOD=0 + else + AC_CACHE_CHECK([whether lchmod works on non-symlinks], + [gl_cv_func_lchmod_works], + [AC_RUN_IFELSE( + [AC_LANG_PROGRAM( + [ + AC_INCLUDES_DEFAULT[ + #ifndef S_IRUSR + #define S_IRUSR 0400 + #endif + #ifndef S_IWUSR + #define S_IWUSR 0200 + #endif + #ifndef S_IRWXU + #define S_IRWXU 0700 + #endif + #ifndef S_IRWXG + #define S_IRWXG 0070 + #endif + #ifndef S_IRWXO + #define S_IRWXO 0007 + #endif + ]], + [[ + int permissive = S_IRWXU | S_IRWXG | S_IRWXO; + int desired = S_IRUSR | S_IWUSR; + static char const f[] = "conftest.lchmod"; + struct stat st; + if (creat (f, permissive) < 0) + return 1; + if (lchmod (f, desired) != 0) + return 1; + if (stat (f, &st) != 0) + return 1; + return ! ((st.st_mode & permissive) == desired); + ]])], + [gl_cv_func_lchmod_works=yes], + [gl_cv_func_lchmod_works=no], + [gl_cv_func_lchmod_works=$gl_cross_guess_normal]) + rm -f conftest.lchmod]) + case $gl_cv_func_lchmod_works in + *yes) ;; + *) REPLACE_LCHMOD=1;; + esac fi ]) diff --git a/m4/sys_stat_h.m4 b/m4/sys_stat_h.m4 index d63df9ebf..a5f35d46d 100644 --- a/m4/sys_stat_h.m4 +++ b/m4/sys_stat_h.m4 @@ -1,4 +1,4 @@ -# sys_stat_h.m4 serial 31 -*- Autoconf -*- +# sys_stat_h.m4 serial 32 -*- Autoconf -*- dnl Copyright (C) 2006-2020 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -88,9 +88,11 @@ AC_DEFUN([gl_SYS_STAT_H_DEFAULTS], HAVE_MKNOD=1; AC_SUBST([HAVE_MKNOD]) HAVE_MKNODAT=1; AC_SUBST([HAVE_MKNODAT]) HAVE_UTIMENSAT=1; AC_SUBST([HAVE_UTIMENSAT]) + REPLACE_FCHMODAT=0; AC_SUBST([REPLACE_FCHMODAT]) REPLACE_FSTAT=0; AC_SUBST([REPLACE_FSTAT]) REPLACE_FSTATAT=0; AC_SUBST([REPLACE_FSTATAT]) REPLACE_FUTIMENS=0; AC_SUBST([REPLACE_FUTIMENS]) + REPLACE_LCHMOD=0; AC_SUBST([REPLACE_LCHMOD]) REPLACE_LSTAT=0; AC_SUBST([REPLACE_LSTAT]) REPLACE_MKDIR=0; AC_SUBST([REPLACE_MKDIR]) REPLACE_MKFIFO=0; AC_SUBST([REPLACE_MKFIFO]) diff --git a/modules/fchmodat b/modules/fchmodat index 7a5e1a688..b0f06e862 100644 --- a/modules/fchmodat +++ b/modules/fchmodat @@ -12,17 +12,21 @@ sys_stat extensions at-internal [test $HAVE_FCHMODAT = 0] dosname [test $HAVE_FCHMODAT = 0] -errno [test $HAVE_FCHMODAT = 0] +errno [test $HAVE_FCHMODAT = 0 || test $REPLACE_FCHMODAT = 1] extern-inline [test $HAVE_FCHMODAT = 0] fchdir [test $HAVE_FCHMODAT = 0] -fcntl-h [test $HAVE_FCHMODAT = 0] +fcntl-h [test $HAVE_FCHMODAT = 0 || test $REPLACE_FCHMODAT = 1] +fstatat [test $REPLACE_FCHMODAT = 1] +intprops [test $HAVE_FCHMODAT = 0 || test $REPLACE_FCHMODAT = 1] +lchmod [test $HAVE_FCHMODAT = 0] openat-die [test $HAVE_FCHMODAT = 0] openat-h [test $HAVE_FCHMODAT = 0] save-cwd [test $HAVE_FCHMODAT = 0] +unistd [test $HAVE_FCHMODAT = 0 || test $REPLACE_FCHMODAT = 1] configure.ac: gl_FUNC_FCHMODAT -if test $HAVE_FCHMODAT = 0; then +if test $HAVE_FCHMODAT = 0 || test $REPLACE_FCHMODAT = 1; then AC_LIBOBJ([fchmodat]) fi gl_MODULE_INDICATOR([fchmodat]) dnl for lib/openat.h diff --git a/modules/lchmod b/modules/lchmod index a0ac7a534..e1054f6a4 100644 --- a/modules/lchmod +++ b/modules/lchmod @@ -2,17 +2,28 @@ Description: lchmod that is actually chmod (!) on hosts lacking lchmod Files: +lib/lchmod.c m4/lchmod.m4 Depends-on: -sys_stat +errno [test $HAVE_LCHMOD = 0 || test $REPLACE_LCHMOD = 1] extensions +fcntl-h [test $HAVE_LCHMOD = 0 || test $REPLACE_LCHMOD = 1] +fchmodat [test $HAVE_LCHMOD = 0 || test $REPLACE_LCHMOD = 1] +intprops [test $HAVE_LCHMOD = 0 || test $REPLACE_LCHMOD = 1] +lstat [test $HAVE_LCHMOD = 0 || test $REPLACE_LCHMOD = 1] +sys_stat +unistd [test $HAVE_LCHMOD = 0 || test $REPLACE_LCHMOD = 1] configure.ac: gl_FUNC_LCHMOD +if test $HAVE_LCHMOD = 0 || test $REPLACE_LCHMOD = 1; then + AC_LIBOBJ([lchmod]) +fi gl_SYS_STAT_MODULE_INDICATOR([lchmod]) Makefile.am: +lib_SOURCES += lchmod.c Include: diff --git a/modules/sys_stat b/modules/sys_stat index 867cc8549..93e0cf07e 100644 --- a/modules/sys_stat +++ b/modules/sys_stat @@ -59,9 +59,11 @@ sys/stat.h: sys_stat.in.h $(top_builddir)/config.status $(CXXDEFS_H) $(ARG_NONNU -e 's|@''HAVE_MKNOD''@|$(HAVE_MKNOD)|g' \ -e 's|@''HAVE_MKNODAT''@|$(HAVE_MKNODAT)|g' \ -e 's|@''HAVE_UTIMENSAT''@|$(HAVE_UTIMENSAT)|g' \ + -e 's|@''REPLACE_FCHMODAT''@|$(REPLACE_FCHMODAT)|g' \ -e 's|@''REPLACE_FSTAT''@|$(REPLACE_FSTAT)|g' \ -e 's|@''REPLACE_FSTATAT''@|$(REPLACE_FSTATAT)|g' \ -e 's|@''REPLACE_FUTIMENS''@|$(REPLACE_FUTIMENS)|g' \ + -e 's|@''REPLACE_LCHMOD''@|$(REPLACE_LCHMOD)|g' \ -e 's|@''REPLACE_LSTAT''@|$(REPLACE_LSTAT)|g' \ -e 's|@''REPLACE_MKDIR''@|$(REPLACE_MKDIR)|g' \ -e 's|@''REPLACE_MKFIFO''@|$(REPLACE_MKFIFO)|g' \ diff --git a/tests/test-fchmodat.c b/tests/test-fchmodat.c index 395b2b78e..df0f604d8 100644 --- a/tests/test-fchmodat.c +++ b/tests/test-fchmodat.c @@ -22,6 +22,8 @@ SIGNATURE_CHECK (fchmodat, int, (int, const char *, mode_t, int)); #include +#include +#include #include #include "macros.h" @@ -42,5 +44,13 @@ main (void) ASSERT (errno == EBADF); } + /* Test that fchmodat works on non-symlinks, when given + the AT_SYMLINK_NOFOLLOW flag. */ + { + ASSERT (close (creat ("file", 0600)) == 0); + ASSERT (fchmodat (AT_FDCWD, "file", 0700, AT_SYMLINK_NOFOLLOW) == 0); + ASSERT (unlink ("file") == 0); + } + return 0; } -- 2.24.1 --------------CAC4BA9170C59056E7CA3C6D-- From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 12 06:51:51 2020 Received: (at 39236) by debbugs.gnu.org; 12 Feb 2020 11:51:51 +0000 Received: from localhost ([127.0.0.1]:57915 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j1qYZ-0004HK-KY for submit@debbugs.gnu.org; Wed, 12 Feb 2020 06:51:51 -0500 Received: from albireo.enyo.de ([37.24.231.21]:43664) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j1qYX-0004HC-Os for 39236@debbugs.gnu.org; Wed, 12 Feb 2020 06:51:50 -0500 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j1qYQ-0000Oh-NC; Wed, 12 Feb 2020 11:51:42 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1j1qX5-0002DJ-T3; Wed, 12 Feb 2020 12:50:19 +0100 From: Florian Weimer To: Paul Eggert Subject: Re: bug#39236: [musl] coreutils cp mishandles error return from lchmod References: <20200122141557.GA8157@brightrain.aerifal.cx> <87ftg7k1at.fsf@oldenburg2.str.redhat.com> <20200122144243.GZ30412@brightrain.aerifal.cx> <87a76fjzpx.fsf@oldenburg2.str.redhat.com> <20200122220515.GH30412@brightrain.aerifal.cx> <38d0e03d-4718-8085-4474-981fdef9b4b8@cs.ucla.edu> Date: Wed, 12 Feb 2020 12:50:19 +0100 In-Reply-To: <38d0e03d-4718-8085-4474-981fdef9b4b8@cs.ucla.edu> (Paul Eggert's message of "Fri, 7 Feb 2020 16:37:56 -0800") Message-ID: <87zhdonhxg.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 39236 Cc: Florian Weimer , musl@lists.openwall.com, Rich Felker , Gnulib bugs , 39236@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) * Paul Eggert: > On 1/22/20 2:05 PM, Rich Felker wrote: >> I think we're approaching a consensus that glibc should fix this too, >> so then it would just be gnulib matching the fix. > > I installed the attached patch to Gnulib in preparation for the upcoming > glibc fix. The patch causes fchmodat with AT_SYMLINK_NOFOLLOW to work on > non-symlinks, and similarly for lchmod on non-symlinks. The idea is to > avoid this sort of problem in the future, and to let Coreutils etc. work > on older platforms as if glibc 2.32 (or whatever) is already in place. The lchmod implementation based on /proc tickles an XFS bug: From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 12 08:06:24 2020 Received: (at 39236) by debbugs.gnu.org; 12 Feb 2020 13:06:24 +0000 Received: from localhost ([127.0.0.1]:57941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j1rii-00083u-As for submit@debbugs.gnu.org; Wed, 12 Feb 2020 08:06:24 -0500 Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:33216 helo=brightrain.aerifal.cx) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j1rig-00083m-Kj for 39236@debbugs.gnu.org; Wed, 12 Feb 2020 08:06:23 -0500 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1j1riF-0003jo-00; Wed, 12 Feb 2020 13:05:55 +0000 Date: Wed, 12 Feb 2020 08:05:55 -0500 From: Rich Felker To: Florian Weimer Subject: Re: bug#39236: [musl] coreutils cp mishandles error return from lchmod Message-ID: <20200212130555.GX1663@brightrain.aerifal.cx> References: <20200122141557.GA8157@brightrain.aerifal.cx> <87ftg7k1at.fsf@oldenburg2.str.redhat.com> <20200122144243.GZ30412@brightrain.aerifal.cx> <87a76fjzpx.fsf@oldenburg2.str.redhat.com> <20200122220515.GH30412@brightrain.aerifal.cx> <38d0e03d-4718-8085-4474-981fdef9b4b8@cs.ucla.edu> <87zhdonhxg.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zhdonhxg.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 0.6 (/) X-Debbugs-Envelope-To: 39236 Cc: Florian Weimer , musl@lists.openwall.com, Paul Eggert , Gnulib bugs , 39236@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.4 (/) On Wed, Feb 12, 2020 at 12:50:19PM +0100, Florian Weimer wrote: > * Paul Eggert: > > > On 1/22/20 2:05 PM, Rich Felker wrote: > >> I think we're approaching a consensus that glibc should fix this too, > >> so then it would just be gnulib matching the fix. > > > > I installed the attached patch to Gnulib in preparation for the upcoming > > glibc fix. The patch causes fchmodat with AT_SYMLINK_NOFOLLOW to work on > > non-symlinks, and similarly for lchmod on non-symlinks. The idea is to > > avoid this sort of problem in the future, and to let Coreutils etc. work > > on older platforms as if glibc 2.32 (or whatever) is already in place. > > The lchmod implementation based on /proc tickles an XFS bug: > > Uhg, why does Linux even let the fs driver see whether the chmod is being performed via a filename, O_PATH fd, or magic symlink in /proc? It should just be an operation on the inode. Rich From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 12 14:08:03 2020 Received: (at 39236) by debbugs.gnu.org; 12 Feb 2020 19:08:03 +0000 Received: from localhost ([127.0.0.1]:59059 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j1xMh-00004y-08 for submit@debbugs.gnu.org; Wed, 12 Feb 2020 14:08:03 -0500 Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:33232 helo=brightrain.aerifal.cx) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j1xMg-0008WV-9M for 39236@debbugs.gnu.org; Wed, 12 Feb 2020 14:08:02 -0500 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1j1xMM-0004jP-00; Wed, 12 Feb 2020 19:07:42 +0000 Date: Wed, 12 Feb 2020 14:07:42 -0500 From: Rich Felker To: Florian Weimer Subject: Re: bug#39236: [musl] coreutils cp mishandles error return from lchmod Message-ID: <20200212190742.GZ1663@brightrain.aerifal.cx> References: <20200122141557.GA8157@brightrain.aerifal.cx> <87ftg7k1at.fsf@oldenburg2.str.redhat.com> <20200122144243.GZ30412@brightrain.aerifal.cx> <87a76fjzpx.fsf@oldenburg2.str.redhat.com> <20200122220515.GH30412@brightrain.aerifal.cx> <38d0e03d-4718-8085-4474-981fdef9b4b8@cs.ucla.edu> <87zhdonhxg.fsf@mid.deneb.enyo.de> <20200212130555.GX1663@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200212130555.GX1663@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 0.6 (/) X-Debbugs-Envelope-To: 39236 Cc: Florian Weimer , musl@lists.openwall.com, Paul Eggert , Gnulib bugs , 39236@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.4 (/) On Wed, Feb 12, 2020 at 08:05:55AM -0500, Rich Felker wrote: > On Wed, Feb 12, 2020 at 12:50:19PM +0100, Florian Weimer wrote: > > * Paul Eggert: > > > > > On 1/22/20 2:05 PM, Rich Felker wrote: > > >> I think we're approaching a consensus that glibc should fix this too, > > >> so then it would just be gnulib matching the fix. > > > > > > I installed the attached patch to Gnulib in preparation for the upcoming > > > glibc fix. The patch causes fchmodat with AT_SYMLINK_NOFOLLOW to work on > > > non-symlinks, and similarly for lchmod on non-symlinks. The idea is to > > > avoid this sort of problem in the future, and to let Coreutils etc. work > > > on older platforms as if glibc 2.32 (or whatever) is already in place. > > > > The lchmod implementation based on /proc tickles an XFS bug: > > > > > > Uhg, why does Linux even let the fs driver see whether the chmod is > being performed via a filename, O_PATH fd, or magic symlink in /proc? > It should just be an operation on the inode. OK, I don't think it's actually clear from the test that the use of the magic symlink is the cause. It's plausible that XFS just always returns failure on success for this operation, and I don't have XFS to test with. Note that in any case, musl's lchmod/fchmodat is not affected since it always refuses to change symlink modes; I did this because I was worried that chmod on the magic symlink in /proc might pass through not just to the symlink it refers to, but to the symlink target if one exists. With current kernel versions it seems that does not happen; is it safe to assume it doesn't? Further, I've found some inconsistent behavior with ext4: chmod on the magic symlink fails with EOPNOTSUPP as in Florian's test, but fchmod on the O_PATH fd succeeds and changes the symlink mode. This is with 5.4. Cany anyone else confirm this? Is it a problem? Rich From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 12 14:15:09 2020 Received: (at 39236) by debbugs.gnu.org; 12 Feb 2020 19:15:09 +0000 Received: from localhost ([127.0.0.1]:59072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j1xTZ-0000GC-AX for submit@debbugs.gnu.org; Wed, 12 Feb 2020 14:15:09 -0500 Received: from albireo.enyo.de ([37.24.231.21]:51810) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j1xTX-0000G2-PZ for 39236@debbugs.gnu.org; Wed, 12 Feb 2020 14:15:08 -0500 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j1xTR-0004hH-9S; Wed, 12 Feb 2020 19:15:01 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1j1xS6-0004wr-Ni; Wed, 12 Feb 2020 20:13:38 +0100 From: Florian Weimer To: Rich Felker Subject: Re: bug#39236: [musl] coreutils cp mishandles error return from lchmod References: <20200122141557.GA8157@brightrain.aerifal.cx> <87ftg7k1at.fsf@oldenburg2.str.redhat.com> <20200122144243.GZ30412@brightrain.aerifal.cx> <87a76fjzpx.fsf@oldenburg2.str.redhat.com> <20200122220515.GH30412@brightrain.aerifal.cx> <38d0e03d-4718-8085-4474-981fdef9b4b8@cs.ucla.edu> <87zhdonhxg.fsf@mid.deneb.enyo.de> <20200212130555.GX1663@brightrain.aerifal.cx> <20200212190742.GZ1663@brightrain.aerifal.cx> Date: Wed, 12 Feb 2020 20:13:38 +0100 In-Reply-To: <20200212190742.GZ1663@brightrain.aerifal.cx> (Rich Felker's message of "Wed, 12 Feb 2020 14:07:42 -0500") Message-ID: <87h7zvmxel.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 39236 Cc: musl@lists.openwall.com, Paul Eggert , Gnulib bugs , 39236@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) * Rich Felker: > Note that in any case, musl's lchmod/fchmodat is not affected since it > always refuses to change symlink modes; I did this because I was > worried that chmod on the magic symlink in /proc might pass through > not just to the symlink it refers to, but to the symlink target if one > exists. With current kernel versions it seems that does not happen; is > it safe to assume it doesn't? I saw it happen with sshfs over FUSE. 8-/ Yet another reason to put in a check before performing the chmod. > Further, I've found some inconsistent behavior with ext4: chmod on the > magic symlink fails with EOPNOTSUPP as in Florian's test, but fchmod > on the O_PATH fd succeeds and changes the symlink mode. This is with > 5.4. Cany anyone else confirm this? Is it a problem? Interesting. Let me update the other thread.