X-Loop: help-debbugs@HIDDEN Subject: bug#39236: [musl] coreutils cp mishandles error return from lchmod Resent-From: Florian Weimer <fweimer@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-coreutils@HIDDEN Resent-Date: Wed, 22 Jan 2020 14:36:02 +0000 Resent-Message-ID: <handler.39236.B.157970374031892 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: report 39236 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Rich Felker <dalias@HIDDEN> Cc: musl@HIDDEN, 39236 <at> debbugs.gnu.org X-Debbugs-Original-Cc: musl@HIDDEN, bug-coreutils@HIDDEN Received: via spool by submit <at> debbugs.gnu.org id=B.157970374031892 (code B ref -1); Wed, 22 Jan 2020 14:36:02 +0000 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 <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1iuH6Z-0008IG-W0 for submit <at> 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 <fweimer@HIDDEN>) id 1iuH6X-0008I9-6M for submit <at> 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 <fweimer@HIDDEN>) id 1iuH6V-0001e8-Ov for bug-coreutils@HIDDEN; 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 <fweimer@HIDDEN>) id 1iuH6T-00085p-Sk for bug-coreutils@HIDDEN; 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 <fweimer@HIDDEN>) id 1iuH6T-00084a-ML for bug-coreutils@HIDDEN; 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 <fweimer@HIDDEN> References: <20200122141557.GA8157@HIDDEN> Date: Wed, 22 Jan 2020 15:34:18 +0100 In-Reply-To: <20200122141557.GA8157@HIDDEN> (Rich Felker's message of "Wed, 22 Jan 2020 09:15:57 -0500") Message-ID: <87ftg7k1at.fsf@HIDDEN> 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-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> 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
Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) Content-Type: text/plain; charset=utf-8 X-Loop: help-debbugs@HIDDEN From: help-debbugs@HIDDEN (GNU bug Tracking System) To: Florian Weimer <fweimer@HIDDEN> Subject: bug#39236: Acknowledgement ([musl] coreutils cp mishandles error return from lchmod) Message-ID: <handler.39236.B.157970374031892.ack <at> debbugs.gnu.org> References: <87ftg7k1at.fsf@HIDDEN> X-Gnu-PR-Message: ack 39236 X-Gnu-PR-Package: coreutils Reply-To: 39236 <at> debbugs.gnu.org Date: Wed, 22 Jan 2020 14:36:02 +0000 Thank you for filing a new bug report with debbugs.gnu.org. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): bug-coreutils@HIDDEN If you wish to submit further information on this problem, please send it to 39236 <at> debbugs.gnu.org. Please do not send mail to help-debbugs@HIDDEN unless you wish to report a problem with the Bug-tracking system. --=20 39236: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D39236 GNU Bug Tracking System Contact help-debbugs@HIDDEN with problems
X-Loop: help-debbugs@HIDDEN Subject: bug#39236: [musl] coreutils cp mishandles error return from lchmod Resent-From: Florian Weimer <fweimer@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-coreutils@HIDDEN Resent-Date: Wed, 22 Jan 2020 15:09:02 +0000 Resent-Message-ID: <handler.39236.B39236.15797057214329 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 39236 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Rich Felker <dalias@HIDDEN> Cc: musl@HIDDEN, 39236 <at> debbugs.gnu.org Received: via spool by 39236-submit <at> debbugs.gnu.org id=B39236.15797057214329 (code B ref 39236); Wed, 22 Jan 2020 15:09:02 +0000 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 <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1iuHcW-00017l-UP for submit <at> 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 <fweimer@HIDDEN>) id 1iuHcV-00017Y-42 for 39236 <at> 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 <fweimer@HIDDEN> References: <20200122141557.GA8157@HIDDEN> <87ftg7k1at.fsf@HIDDEN> <20200122144243.GZ30412@HIDDEN> Date: Wed, 22 Jan 2020 16:08:26 +0100 In-Reply-To: <20200122144243.GZ30412@HIDDEN> (Rich Felker's message of "Wed, 22 Jan 2020 09:42:43 -0500") Message-ID: <87a76fjzpx.fsf@HIDDEN> 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-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> 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
X-Loop: help-debbugs@HIDDEN Subject: bug#39236: [musl] coreutils cp mishandles error return from lchmod Resent-From: Florian Weimer <fweimer@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-coreutils@HIDDEN Resent-Date: Wed, 22 Jan 2020 15:33:02 +0000 Resent-Message-ID: <handler.39236.B39236.15797071806755 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 39236 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Rich Felker <dalias@HIDDEN> Cc: musl@HIDDEN, 39236 <at> debbugs.gnu.org Received: via spool by 39236-submit <at> debbugs.gnu.org id=B39236.15797071806755 (code B ref 39236); Wed, 22 Jan 2020 15:33:02 +0000 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 <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1iuI04-0001kt-2S for submit <at> 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 <fweimer@HIDDEN>) id 1iuI02-0001kf-H3 for 39236 <at> 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 <fweimer@HIDDEN> References: <20200122141557.GA8157@HIDDEN> <87ftg7k1at.fsf@HIDDEN> <20200122144243.GZ30412@HIDDEN> <87a76fjzpx.fsf@HIDDEN> <20200122151507.GB30412@HIDDEN> Date: Wed, 22 Jan 2020 16:32:45 +0100 In-Reply-To: <20200122151507.GB30412@HIDDEN> (Rich Felker's message of "Wed, 22 Jan 2020 10:15:07 -0500") Message-ID: <87zhefik0y.fsf@HIDDEN> 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-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> 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
X-Loop: help-debbugs@HIDDEN Subject: bug#39236: [musl] coreutils cp mishandles error return from lchmod Resent-From: Rich Felker <dalias@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-coreutils@HIDDEN Resent-Date: Wed, 22 Jan 2020 16:01:01 +0000 Resent-Message-ID: <handler.39236.B.15797088039344 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 39236 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Florian Weimer <fweimer@HIDDEN> Cc: musl@HIDDEN, 39236 <at> debbugs.gnu.org X-Debbugs-Original-Cc: musl@HIDDEN, bug-coreutils@HIDDEN Received: via spool by submit <at> debbugs.gnu.org id=B.15797088039344 (code B ref -1); Wed, 22 Jan 2020 16:01:01 +0000 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 <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1iuIQE-0002QV-7E for submit <at> 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 <dalias@HIDDEN>) id 1iuHDm-0008U7-C4 for submit <at> 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 <dalias@HIDDEN>) id 1iuHDl-0005FV-BP for bug-coreutils@HIDDEN; 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 <dalias@HIDDEN>) id 1iuHDk-00050T-Fe for bug-coreutils@HIDDEN; 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 <dalias@HIDDEN>) id 1iuHDk-0004zE-As for bug-coreutils@HIDDEN; 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 <dalias@HIDDEN> Message-ID: <20200122144243.GZ30412@HIDDEN> References: <20200122141557.GA8157@HIDDEN> <87ftg7k1at.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ftg7k1at.fsf@HIDDEN> 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-Mailman-Approved-At: Wed, 22 Jan 2020 11:00:00 -0500 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> 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
X-Loop: help-debbugs@HIDDEN Subject: bug#39236: [musl] coreutils cp mishandles error return from lchmod Resent-From: Rich Felker <dalias@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-coreutils@HIDDEN Resent-Date: Wed, 22 Jan 2020 16:01:02 +0000 Resent-Message-ID: <handler.39236.B39236.15797088039364 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 39236 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Florian Weimer <fweimer@HIDDEN> Cc: musl@HIDDEN, 39236 <at> debbugs.gnu.org Received: via spool by 39236-submit <at> debbugs.gnu.org id=B39236.15797088039364 (code B ref 39236); Wed, 22 Jan 2020 16:01:02 +0000 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 <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1iuIQE-0002Qd-QK for submit <at> 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 <dalias@HIDDEN>) id 1iuHit-0001II-5S for 39236 <at> 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 <dalias@HIDDEN> Message-ID: <20200122151507.GB30412@HIDDEN> References: <20200122141557.GA8157@HIDDEN> <87ftg7k1at.fsf@HIDDEN> <20200122144243.GZ30412@HIDDEN> <87a76fjzpx.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a76fjzpx.fsf@HIDDEN> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 0.6 (/) X-Mailman-Approved-At: Wed, 22 Jan 2020 11:00:00 -0500 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> 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
X-Loop: help-debbugs@HIDDEN Subject: bug#39236: [musl] coreutils cp mishandles error return from lchmod Resent-From: Rich Felker <dalias@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-coreutils@HIDDEN Resent-Date: Wed, 22 Jan 2020 16:08:02 +0000 Resent-Message-ID: <handler.39236.B39236.157970928010203 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 39236 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Florian Weimer <fweimer@HIDDEN> Cc: musl@HIDDEN, 39236 <at> debbugs.gnu.org Received: via spool by 39236-submit <at> debbugs.gnu.org id=B39236.157970928010203 (code B ref 39236); Wed, 22 Jan 2020 16:08:02 +0000 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 <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1iuIXw-0002eU-57 for submit <at> 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 <dalias@HIDDEN>) id 1iuIXu-0002eM-Ls for 39236 <at> 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 <dalias@HIDDEN> Message-ID: <20200122160743.GC30412@HIDDEN> References: <20200122141557.GA8157@HIDDEN> <87ftg7k1at.fsf@HIDDEN> <20200122144243.GZ30412@HIDDEN> <87a76fjzpx.fsf@HIDDEN> <20200122151507.GB30412@HIDDEN> <87zhefik0y.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zhefik0y.fsf@HIDDEN> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 0.6 (/) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> 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
X-Loop: help-debbugs@HIDDEN Subject: bug#39236: [musl] coreutils cp mishandles error return from lchmod Resent-From: Florian Weimer <fweimer@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-coreutils@HIDDEN Resent-Date: Wed, 22 Jan 2020 16:20:02 +0000 Resent-Message-ID: <handler.39236.B39236.157970995419024 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 39236 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Rich Felker <dalias@HIDDEN> Cc: musl@HIDDEN, 39236 <at> debbugs.gnu.org Received: via spool by 39236-submit <at> debbugs.gnu.org id=B39236.157970995419024 (code B ref 39236); Wed, 22 Jan 2020 16:20:02 +0000 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 <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1iuIio-0004wl-Eq for submit <at> 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 <fweimer@HIDDEN>) id 1iuIim-0004wd-JR for 39236 <at> 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 <fweimer@HIDDEN> References: <20200122141557.GA8157@HIDDEN> <87ftg7k1at.fsf@HIDDEN> <20200122144243.GZ30412@HIDDEN> <87a76fjzpx.fsf@HIDDEN> <20200122151507.GB30412@HIDDEN> <87zhefik0y.fsf@HIDDEN> <20200122160743.GC30412@HIDDEN> Date: Wed, 22 Jan 2020 17:19:05 +0100 In-Reply-To: <20200122160743.GC30412@HIDDEN> (Rich Felker's message of "Wed, 22 Jan 2020 11:07:43 -0500") Message-ID: <87v9p3ihvq.fsf@HIDDEN> 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-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> 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
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.