From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <musl-return-15434-ml=inbox.vuxu.org@lists.openwall.com>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,
	RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2
Received: from mother.openwall.net (mother.openwall.net [195.42.179.200])
	by inbox.vuxu.org (OpenSMTPD) with SMTP id 0394fdae
	for <ml@inbox.vuxu.org>;
	Wed, 12 Feb 2020 19:15:19 +0000 (UTC)
Received: (qmail 4039 invoked by uid 550); 12 Feb 2020 19:15:17 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 4018 invoked from network); 12 Feb 2020 19:15:17 -0000
From: Florian Weimer <fw@deneb.enyo.de>
To: Rich Felker <dalias@libc.org>
Cc: Paul Eggert <eggert@cs.ucla.edu>,   Gnulib bugs <bug-gnulib@gnu.org>,
	musl@lists.openwall.com,  39236@debbugs.gnu.org
References: <20200122141557.GA8157@brightrain.aerifal.cx>
	<87ftg7k1at.fsf@oldenburg2.str.redhat.com>
	<20200122144243.GZ30412@brightrain.aerifal.cx>
	<87a76fjzpx.fsf@oldenburg2.str.redhat.com>
	<ffd99ae1-5a4a-0cd7-b33a-7fc51b8fb3e6@cs.ucla.edu>
	<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
Subject: Re: bug#39236: [musl] coreutils cp mishandles error return from lchmod

* 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.