GNU bug report logs - #39236
[musl] coreutils cp mishandles error return from lchmod

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: coreutils; Reported by: Florian Weimer <fweimer@HIDDEN>; dated Wed, 22 Jan 2020 14:36:02 UTC; Maintainer for coreutils is bug-coreutils@HIDDEN.

Message received at 39236 <at> debbugs.gnu.org:


Received: (at 39236) by debbugs.gnu.org; 22 Jan 2020 16:19:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 22 11:19:14 2020
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>
To: Rich Felker <dalias@HIDDEN>
Subject: Re: [musl] coreutils cp mishandles error return from lchmod
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-Debbugs-Envelope-To: 39236
Cc: musl@HIDDEN, 39236 <at> debbugs.gnu.org
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





Information forwarded to bug-coreutils@HIDDEN:
bug#39236; Package coreutils. Full text available.

Message received at 39236 <at> debbugs.gnu.org:


Received: (at 39236) by debbugs.gnu.org; 22 Jan 2020 16:08:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 22 11:08:00 2020
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>
To: Florian Weimer <fweimer@HIDDEN>
Subject: Re: [musl] coreutils cp mishandles error return from lchmod
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-Debbugs-Envelope-To: 39236
Cc: musl@HIDDEN, 39236 <at> debbugs.gnu.org
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




Information forwarded to bug-coreutils@HIDDEN:
bug#39236; Package coreutils. Full text available.

Message received at 39236 <at> debbugs.gnu.org:


Received: (at 39236) by debbugs.gnu.org; 22 Jan 2020 16:00:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 22 11:00:03 2020
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>
To: Florian Weimer <fweimer@HIDDEN>
Subject: Re: [musl] coreutils cp mishandles error return from lchmod
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-Debbugs-Envelope-To: 39236
X-Mailman-Approved-At: Wed, 22 Jan 2020 11:00:00 -0500
Cc: musl@HIDDEN, 39236 <at> debbugs.gnu.org
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




Information forwarded to bug-coreutils@HIDDEN:
bug#39236; Package coreutils. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 22 Jan 2020 16:00:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 22 11:00:02 2020
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>
To: Florian Weimer <fweimer@HIDDEN>
Subject: Re: [musl] coreutils cp mishandles error return from lchmod
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-Debbugs-Envelope-To: submit
X-Mailman-Approved-At: Wed, 22 Jan 2020 11:00:00 -0500
Cc: musl@HIDDEN, bug-coreutils@HIDDEN
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




Information forwarded to bug-coreutils@HIDDEN:
bug#39236; Package coreutils. Full text available.

Message received at 39236 <at> debbugs.gnu.org:


Received: (at 39236) by debbugs.gnu.org; 22 Jan 2020 15:33:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 22 10:33:00 2020
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>
To: Rich Felker <dalias@HIDDEN>
Subject: Re: [musl] coreutils cp mishandles error return from lchmod
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-Debbugs-Envelope-To: 39236
Cc: musl@HIDDEN, 39236 <at> debbugs.gnu.org
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





Information forwarded to bug-coreutils@HIDDEN:
bug#39236; Package coreutils. Full text available.

Message received at 39236 <at> debbugs.gnu.org:


Received: (at 39236) by debbugs.gnu.org; 22 Jan 2020 15:08:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 22 10:08:41 2020
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>
To: Rich Felker <dalias@HIDDEN>
Subject: Re: [musl] coreutils cp mishandles error return from lchmod
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-Debbugs-Envelope-To: 39236
Cc: musl@HIDDEN, 39236 <at> debbugs.gnu.org
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





Information forwarded to bug-coreutils@HIDDEN:
bug#39236; Package coreutils. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 22 Jan 2020 14:35:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 22 09:35:40 2020
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>
To: Rich Felker <dalias@HIDDEN>
Subject: Re: [musl] coreutils cp mishandles error return from lchmod
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-Debbugs-Envelope-To: submit
Cc: musl@HIDDEN, bug-coreutils@HIDDEN
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





Acknowledgement sent to Florian Weimer <fweimer@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-coreutils@HIDDEN. Full text available.
Report forwarded to bug-coreutils@HIDDEN:
bug#39236; Package coreutils. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Wed, 22 Jan 2020 16:30:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.