GNU logs - #9446, boring messages

Message sent to owner <at> debbugs.gnu.org, bug-coreutils@HIDDEN:

Subject: bug#9446: Bug in cp (or strange behaviour and unclear documentation)
Resent-From: Torbjorn Granlund <tg@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-To: owner <at> debbugs.gnu.org
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Mon, 05 Sep 2011 23:03:01 +0000
Resent-Message-ID: <handler.9446.B.131526377722764 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 9446 <at> debbugs.gnu.org
From: Torbjorn Granlund <tg@HIDDEN>
Date: Mon, 05 Sep 2011 21:26:19 +0200
Message-ID: <86zkiirdt0.fsf@HIDDEN>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

On FreeBSD (tested on 8.1, but exact version is unlikely relevant)
copying a file from a ZFS file system to a tmpfs or tmpmfs filesystem,
the -p option causes cp to return with a non-zero exit status.

Sample run:

$ cp -p /etc/profile /tmp/foo || echo non-zero exit
cp: preserving permissions for `/tmp/foo': Invalid argument
non-zero exit

Some debugging shows that the function acl_access_nontrivial returns 1,
caused by the tag ACL_EVERYONE.  (It is present in every file by
default.)

ACLs are not supported on FreeBSD's tmpfs or tmpmfs file system types.

Perhaps this failure is intentional?  Then it should be clearly
documented for the -p/--preserve option.  I have read it carefully, and
I cannot see support for the observed behaviour.

Consider what happens under -p when copying a file owned by somebody
else.  The used and group owners can then not (typically) be preserved.
This is not considered an error in cp.

Similarly, when copying a file with the setuid bit set, and the user is
changed (per above) the setuid bit is not preserved, and this is also
not considered an error by cp.

The failure to preserve (partial) ACL data should IMHO not be considered
an error, except perhaps under some --preserve=3Dblah options, where blah
denoted preservation of exactly this.

--=20
Torbj=F6rn

(Since I am the original author of cp, I suppose I should really fix the
problem myself.  But I think the ACL stuff was added later, and I am not
familiar with it.)

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Torbjorn Granlund <tg@HIDDEN>
Subject: bug#9446: Acknowledgement (Bug in cp (or strange behaviour and
 unclear documentation))
Message-ID: <handler.9446.B.131526377722764.ack <at> debbugs.gnu.org>
References: <86zkiirdt0.fsf@HIDDEN>
X-Gnu-PR-Message: ack 9446
X-Gnu-PR-Package: coreutils
Reply-To: 9446 <at> debbugs.gnu.org
Date: Mon, 05 Sep 2011 23:03:02 +0000

Thank you for filing a new bug report with GNU.

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 9446 <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
9446: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D9446
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to owner <at> debbugs.gnu.org, bug-coreutils@HIDDEN:

Subject: bug#9446: Bug in cp (or strange behaviour and unclear documentation)
Resent-From: Jim Meyering <jim@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-To: owner <at> debbugs.gnu.org
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Tue, 06 Sep 2011 07:12:02 +0000
Resent-Message-ID: <handler.9446.B9446.131529308918312 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Torbjorn Granlund <tg@HIDDEN>
Cc: 9446 <at> debbugs.gnu.org
From: Jim Meyering <jim@HIDDEN>
In-Reply-To: <86zkiirdt0.fsf@HIDDEN> (Torbjorn Granlund's message of
	"Mon, 05 Sep 2011 21:26:19 +0200")
References: <86zkiirdt0.fsf@HIDDEN>
Date: Tue, 06 Sep 2011 09:07:35 +0200
Message-ID: <877h5m4094.fsf@HIDDEN>
Lines: 56
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

Torbjorn Granlund wrote:
> On FreeBSD (tested on 8.1, but exact version is unlikely relevant)
> copying a file from a ZFS file system to a tmpfs or tmpmfs filesystem,
> the -p option causes cp to return with a non-zero exit status.
>
> Sample run:
>
> $ cp -p /etc/profile /tmp/foo || echo non-zero exit
> cp: preserving permissions for `/tmp/foo': Invalid argument
> non-zero exit
>
> Some debugging shows that the function acl_access_nontrivial returns 1,
> caused by the tag ACL_EVERYONE.  (It is present in every file by
> default.)
>
> ACLs are not supported on FreeBSD's tmpfs or tmpmfs file system types.
>
> Perhaps this failure is intentional?  Then it should be clearly
> documented for the -p/--preserve option.  I have read it carefully, and
> I cannot see support for the observed behaviour.
>
> Consider what happens under -p when copying a file owned by somebody
> else.  The used and group owners can then not (typically) be preserved.
> This is not considered an error in cp.
>
> Similarly, when copying a file with the setuid bit set, and the user is
> changed (per above) the setuid bit is not preserved, and this is also
> not considered an error by cp.
>
> The failure to preserve (partial) ACL data should IMHO not be considered
> an error, except perhaps under some --preserve=blah options, where blah
> denoted preservation of exactly this.

Hi!
Long time ;-)

ACL-preservation has always been lumped in with the
permission-preservation that you get with cp's "-p".
However, that is not POSIX-mandated.

This is the responsible code in copy.c:

  if (x->preserve_mode || x->move_mode)
    {
      if (copy_acl (src_name, -1, dst_name, -1, src_mode) != 0
          && x->require_preserve)
        return false;
    }

However, upon copy_acl failure, rather than simply returning false, it
might be ok to return true for EINVAL, or even to perform a relatively
expensive test (the first time for each FS) to see if the failure is
due to lack of ACL support in the destination file system.

I'm less inclined to add a separate --preserve=acl option, because
that would involve a behavior change (of not copying ACLs by default).

Message sent to owner <at> debbugs.gnu.org, bug-coreutils@HIDDEN:

Subject: bug#9446: Bug in cp (or strange behaviour and unclear documentation)
Resent-From: =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-To: owner <at> debbugs.gnu.org
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Tue, 06 Sep 2011 09:09:01 +0000
Resent-Message-ID: <handler.9446.B9446.131530010416915 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Jim Meyering <jim@HIDDEN>
Cc: 9446 <at> debbugs.gnu.org, Torbjorn Granlund <tg@HIDDEN>
Message-ID: <4E65E219.4010802@HIDDEN>
Date: Tue, 06 Sep 2011 10:04:25 +0100
From: =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:5.0) Gecko/20110707 Thunderbird/5.0
MIME-Version: 1.0
References: <86zkiirdt0.fsf@HIDDEN> <877h5m4094.fsf@HIDDEN>
In-Reply-To: <877h5m4094.fsf@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

On 09/06/2011 08:07 AM, Jim Meyering wrote:
> Torbjorn Granlund wrote:
>> On FreeBSD (tested on 8.1, but exact version is unlikely relevant)
>> copying a file from a ZFS file system to a tmpfs or tmpmfs filesystem,
>> the -p option causes cp to return with a non-zero exit status.
>>
>> Sample run:
>>
>> $ cp -p /etc/profile /tmp/foo || echo non-zero exit
>> cp: preserving permissions for `/tmp/foo': Invalid argument
>> non-zero exit
>>
>> Some debugging shows that the function acl_access_nontrivial returns 1,
>> caused by the tag ACL_EVERYONE.  (It is present in every file by
>> default.)
>>
>> ACLs are not supported on FreeBSD's tmpfs or tmpmfs file system types.
>>
>> Perhaps this failure is intentional?  Then it should be clearly
>> documented for the -p/--preserve option.  I have read it carefully, and
>> I cannot see support for the observed behaviour.
>>
>> Consider what happens under -p when copying a file owned by somebody
>> else.  The used and group owners can then not (typically) be preserved.
>> This is not considered an error in cp.
>>
>> Similarly, when copying a file with the setuid bit set, and the user is
>> changed (per above) the setuid bit is not preserved, and this is also
>> not considered an error by cp.
>>
>> The failure to preserve (partial) ACL data should IMHO not be considered
>> an error, except perhaps under some --preserve=blah options, where blah
>> denoted preservation of exactly this.
> 
> Hi!
> Long time ;-)
> 
> ACL-preservation has always been lumped in with the
> permission-preservation that you get with cp's "-p".
> However, that is not POSIX-mandated.
> 
> This is the responsible code in copy.c:
> 
>   if (x->preserve_mode || x->move_mode)
>     {
>       if (copy_acl (src_name, -1, dst_name, -1, src_mode) != 0
>           && x->require_preserve)
>         return false;
>     }
> 
> However, upon copy_acl failure, rather than simply returning false, it
> might be ok to return true for EINVAL, or even to perform a relatively
> expensive test (the first time for each FS) to see if the failure is
> due to lack of ACL support in the destination file system.
> 
> I'm less inclined to add a separate --preserve=acl option, because
> that would involve a behavior change (of not copying ACLs by default).

I agree. It's like ACLs span both --preserve=mode and --preserve=xattrs (if possible).
The trivial ACLs are already made optional within copy_acl()
assuming I suppose that the dest will record this info anyway.

So what to do if other ACLs can't be preserved.
Ideally I think we'd like to:
  1. Warn once per cp invocation about unpreserved non trivial ACLs
  2. With --verbose, warn per file, which ACLs were not preserved.
  3. if !ACL_NOT_WELL_SUPPORTED(errno) exit 1

As an interim measure we could just do 3, which would give
many non specific "preserving permissions" errors,
but at least exit appropriately.

cheers,
P�draig.

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

Received: (at control) by debbugs.gnu.org; 15 Oct 2018 14:06:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 15 10:06:07 2018
Received: from localhost ([127.0.0.1]:50838 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1gC3VX-0006u9-Ec
	for submit <at> debbugs.gnu.org; Mon, 15 Oct 2018 10:06:07 -0400
Received: from mail-pf1-f181.google.com ([209.85.210.181]:45055)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <assafgordon@HIDDEN>) id 1gC3VV-0006tg-UX
 for control <at> debbugs.gnu.org; Mon, 15 Oct 2018 10:06:06 -0400
Received: by mail-pf1-f181.google.com with SMTP id r9-v6so9729297pff.11
 for <control <at> debbugs.gnu.org>; Mon, 15 Oct 2018 07:06:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=to:from:message-id:date:user-agent:mime-version:content-language
 :content-transfer-encoding;
 bh=tslEaETexaL5Plma/unGTsX6EP4DKD4xeOJEPvCMxto=;
 b=IgYFBuphZeO6ufK2R0ThohvlgQjuhoNFWS1LlcCSo1fBUKysCs/zlabxiMQtbAEcv9
 5lGZ2r6pLOmV6xqrPS+qDt2TeNf9PdqM87PuEWn/4x620EkidrGhTUDmK8QpzgVQzVAQ
 EbQlLs3N5jp0ConLqnjfIhq7aDCn8Xl50ynhkCdy0fANLzrY2EvRmD3m7uMjb5jb+xqH
 xS/hKhgbCyjDaI3jvxizDo6EABMqsRi+3b0sr7dxdtRTv6KUKh7gQ5PU0nHQE8YeQONT
 P9HPFS0vFx2QnpJxGkZmXHf+3XGL8HKXvVuDTlSNkqF/qZTLVqCRMbMCWIvHt6+ZEs5y
 n3hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:to:from:message-id:date:user-agent:mime-version
 :content-language:content-transfer-encoding;
 bh=tslEaETexaL5Plma/unGTsX6EP4DKD4xeOJEPvCMxto=;
 b=BN3r7OXN8tmVFFClh/JaAHUbBcnAdSXiJ67IUn+im2fR1JlCkyNstmy7CewveTl3rI
 vnSXQ19OdA6Qp1kJFBuaGcoNBRzwMYw41tD8vZGNs6p+KVkRqseq9FvSPMt0jSjTDPMX
 mTl7/OUUicxSa42ymRGVWKwy+eldyLKFF2WgL6mhMSZZXaqgQHErZbsyshfA9Tm1AP9n
 m5S7nzWYoRABBjQeUfpMZUOTVocTfC2NLLWQ7t3voQlPJH4k+FeCZC+MqQN/p+8OPxzU
 kFK3LSse0N4xr5hs4MNgeUfpxgSUlJWXlkBAjD74LRDzK9UzaXZnfGEpez1iMWr9MNLu
 oS0A==
X-Gm-Message-State: ABuFfogF5FahDcLajf6++HIxsfi3VRUE8JU/09QQUb42o/IqgSydVRRq
 3Vo6uKUbR8M+YV87LQ8Js2Dg6zzjDqI=
X-Google-Smtp-Source: ACcGV630bCAJkl8c383Nvxde4mlHBbauHW61q0zd37Y2dEOjIhXh0u6sXrtKgN3rwQfCYT0iTqNkyg==
X-Received: by 2002:a62:67c3:: with SMTP id
 t64-v6mr10225425pfj.76.1539612359472; 
 Mon, 15 Oct 2018 07:05:59 -0700 (PDT)
Received: from tomato.housegordon.com (moose.housegordon.com. [184.68.105.38])
 by smtp.googlemail.com with ESMTPSA id
 h77-v6sm21227916pfh.13.2018.10.15.07.05.57
 for <control <at> debbugs.gnu.org>
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 15 Oct 2018 07:05:57 -0700 (PDT)
To: control <at> debbugs.gnu.org
From: Assaf Gordon <assafgordon@HIDDEN>
Message-ID: <b1e0e40e-d722-270a-27d8-972ceaf1ec2b@HIDDEN>
Date: Mon, 15 Oct 2018 08:05:56 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: severity 9365 wishlist retitle 9365 multibyte: tr: TR
 operates
 on bytes, not characters retitle 9446 cp: acl preservation problem on FreeBSD
 8.1 severity 9472 wishlist [...] 
 Content analysis details:   (2.0 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
 (assafgordon[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [209.85.210.181 listed in wl.mailspike.net]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
 trust [209.85.210.181 listed in list.dnswl.org]
 1.8 MISSING_SUBJECT        Missing Subject: header
 0.2 NO_SUBJECT             Extra score for no subject
 0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
X-Debbugs-Envelope-To: control
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 (+)

severity 9365 wishlist
retitle 9365 multibyte: tr: TR operates on bytes, not characters


retitle 9446 cp: acl preservation problem on FreeBSD 8.1

severity 9472 wishlist

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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