From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: master fails to build on FreeBSD when ACL support is on Date: Mon, 22 Jan 2018 10:50:59 -0800 Organization: UCLA Computer Science Department Message-ID: References: <86o9lua0yx.fsf@phe.ftfl.ca> <834lnly8ht.fsf@gnu.org> <86vafy20sj.fsf@phe.ftfl.ca> <83o9lpuct5.fsf@gnu.org> <83lggtu1qn.fsf@gnu.org> <9dd64b10-78ce-c561-8c51-9e15b11e102c@cs.ucla.edu> <83bmhpt12i.fsf@gnu.org> <867escw93p.fsf@phe.ftfl.ca> <86vafwumqp.fsf@phe.ftfl.ca> <025ce2fd-a69a-12da-ce5b-c894d5636789@cs.ucla.edu> <83372zryx3.fsf@gnu.org> <4928e09c-e747-8754-973f-7b358ca3f5e7@cs.ucla.edu> <83inbtriv1.fsf@gnu.org> <83zi55zt7m.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1516646993 6353 195.159.176.226 (22 Jan 2018 18:49:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 22 Jan 2018 18:49:53 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 Cc: jrm@ftfl.ca, ashish@FreeBSD.org, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 22 19:49:49 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1edhA6-0000wn-QX for ged-emacs-devel@m.gmane.org; Mon, 22 Jan 2018 19:49:42 +0100 Original-Received: from localhost ([::1]:58809 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1edhC7-00058d-8A for ged-emacs-devel@m.gmane.org; Mon, 22 Jan 2018 13:51:47 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47021) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1edhBS-00057Q-9G for emacs-devel@gnu.org; Mon, 22 Jan 2018 13:51:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1edhBR-00068I-J9 for emacs-devel@gnu.org; Mon, 22 Jan 2018 13:51:06 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:35008) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1edhBN-00066p-Rf; Mon, 22 Jan 2018 13:51:01 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2B04A161248; Mon, 22 Jan 2018 10:51:00 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id on7hIkFSLg2v; Mon, 22 Jan 2018 10:50:59 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5B0F016147C; Mon, 22 Jan 2018 10:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Qzlysi_5oUQA; Mon, 22 Jan 2018 10:50:59 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 3E582161248; Mon, 22 Jan 2018 10:50:59 -0800 (PST) In-Reply-To: <83zi55zt7m.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:222152 Archived-At: On 01/22/2018 09:41 AM, Eli Zaretskii wrote: > Why do we need to inform the callers that ACL setting failed Because they invoked copy-file with a non-nil preserve-permissions flag, and copy-file cannot preserve the permissions as requested. It's the same reason copy-file signals an error when invoked with a non-nil keep-time flag and when it cannot keep the time on the output file. If copy-file did not report an error, users would be lulled into thinking that the destination has the same permissions as the source when copy-file succeeds, even though that's not the case. There is some precedent for ignoring failure, as copy-file does ignore chown failure when the preserve-uid-gid flag is used. However, this behavior is documented as a specific exception to the general rule that copy-file signals failures. One way to move forward would be to change copy-file to have a three-way result, as set-file-acl does. That is, it could return t if successful, nil if mildly unsuccessful, and signal an error if severely unsuccessful. Failure to preserve UID and GID would be considered mild. Perhaps failure to preserve permissions could be considered mild, too, since it's no more security-relevant than UID failure is.