From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Barzilay Newsgroups: gmane.emacs.bugs Subject: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc [set-file-extended-attributes] Date: Mon, 19 Oct 2015 05:47:36 -0400 Message-ID: References: <831tcricrz.fsf@gnu.org> <83zizfgxnl.fsf@gnu.org> <83wpujgwr3.fsf@gnu.org> <83si57gu7s.fsf@gnu.org> <83k2qjgqm5.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1445248104 29009 80.91.229.3 (19 Oct 2015 09:48:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Oct 2015 09:48:24 +0000 (UTC) Cc: 21699@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 19 11:48:14 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zo736-0003NW-Lq for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Oct 2015 11:48:12 +0200 Original-Received: from localhost ([::1]:37941 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo735-00041v-Vf for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Oct 2015 05:48:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46974) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo731-00041Y-0l for bug-gnu-emacs@gnu.org; Mon, 19 Oct 2015 05:48:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zo72w-0001PH-Fb for bug-gnu-emacs@gnu.org; Mon, 19 Oct 2015 05:48:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36815) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo72w-0001PD-Bm for bug-gnu-emacs@gnu.org; Mon, 19 Oct 2015 05:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zo72w-0000fh-2C for bug-gnu-emacs@gnu.org; Mon, 19 Oct 2015 05:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Barzilay Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Oct 2015 09:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21699 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21699-submit@debbugs.gnu.org id=B21699.14452480602550 (code B ref 21699); Mon, 19 Oct 2015 09:48:02 +0000 Original-Received: (at 21699) by debbugs.gnu.org; 19 Oct 2015 09:47:40 +0000 Original-Received: from localhost ([127.0.0.1]:55756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo72Z-0000f4-VV for submit@debbugs.gnu.org; Mon, 19 Oct 2015 05:47:40 -0400 Original-Received: from mail-io0-f172.google.com ([209.85.223.172]:34111) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo72X-0000ev-Km for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 05:47:38 -0400 Original-Received: by iow1 with SMTP id 1so183063743iow.1 for <21699@debbugs.gnu.org>; Mon, 19 Oct 2015 02:47:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KuLoY5CywMgscQ9Os1ky+fdeWiyU7Y2vEW0u/rjhafM=; b=gOgi4fCoKUm/voo+uTeqFjGuplXlVA81bScHPkxDYIk6r9qtVwVR782pUh4Rk97W6H 51ZpqvgWJJnsRBSITQoauE2TOYNBIdQTuVG4CiGYEuSJ1kj7zN4+Aq8B0zJCeE4TW1Ww GKfkFa9hTKv4trJUtxtraGmu2fN/TdC6E4VXKa1o2FhAIhXAaidNzRX/lPxdS5LIAYO9 wCpDL+js+Ji2825rOAS01FjjVTwEVZRHiv3qpAS2H0eTOmsO96VfSgTktJ5Fl+KSNo2G zz0Wcb5fTHf9L9lgaUSuLQTDnjXfdC1VMDQYgKaRrZh7nua4iZ6cWIe/3fSBLTbff6tN kCxQ== X-Gm-Message-State: ALoCoQnNtz9+9hRHUCkcFsiGGge1KoOzTmrFptEIWLHIPTxAwAvSpuKfU3YLynuOlTIVNixcaNKD X-Received: by 10.107.137.66 with SMTP id l63mr14963539iod.112.1445248057031; Mon, 19 Oct 2015 02:47:37 -0700 (PDT) Original-Received: by 10.79.28.211 with HTTP; Mon, 19 Oct 2015 02:47:36 -0700 (PDT) In-Reply-To: <83k2qjgqm5.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:107751 Archived-At: On Mon, Oct 19, 2015 at 5:22 AM, Eli Zaretskii wrote: >> Date: Mon, 19 Oct 2015 05:10:58 -0400 >> From: Eli Barzilay >> Cc: 21699@debbugs.gnu.org >> >> On Mon, Oct 19, 2015 at 4:04 AM, Eli Zaretskii wrote: >> >> Date: Mon, 19 Oct 2015 03:50:04 -0400 >> >> From: Eli Barzilay >> >> Cc: 21699@debbugs.gnu.org >> >> >> >> *BUT* I doubt that this is a good idea, since on a system that >> >> supports both acl and selinux-context you probably want a t result to >> >> indicate that all of the extended settings worked. >> > >> > I don't think this is true. Many (maybe most) systems support either >> > ACLs or SELinux, and for them the function will incorrectly return >> > nil. >> > >> > A better way might be to have a test of "null" attributes, and avoid >> > calling the low-level APIs when the attributes are "null". A separate >> > issue, I think. >> >> Did you have a look at my `file-extended-attributes' fix? It does just >> that: when the low-level functions return "null" (four nils in the >> selinux case), then they won't get included in the result. This frees >> `set-file-extended-attributes' to require that all settings succeed. > > Yes, I've seen that. But I'm not sure that we want such a change, > because it loses some information: namely, that the failed interfaces > did fail, or, equivalently, that information about the other kinds of > attributes is not available. OK. > I don't know if this is important, but it does change the semantics of > an interface that was already released. So I preferred a fix that > didn't involve such changes. OK, here's a version that does the decision in `set-file-extended-attributes', making it succeed if all of the given attributes were set but ignoring the "null" values. (Again, I verified that it works in my case.) ------------------------------------------------------------------------------- (defun set-file-extended-attributes (filename attributes) "Set extended attributes of file FILENAME to ATTRIBUTES. ATTRIBUTES must be an alist of file attributes as returned by `file-extended-attributes'. Value is t if the function succeeds in setting all of the given attributes excluding ones that indicate \"no information\"." (let ((result t)) (dolist (elt attributes) (let ((attr (car elt)) (val (cdr elt))) (unless (cond ((eq attr 'acl) (or (equal val nil) (set-file-acl filename val))) ((eq attr 'selinux-context) (or (equal val '(nil nil nil nil)) (set-file-selinux-context filename val)))) (setq result nil)))) result)) ------------------------------------------------------------------------------- >> And I think that there's one case where things would fail with your fix: >> a linux machine that has selinux disabled will have this as the extended >> attributes: >> >> ((acl . nil) (selinux-context . (nil nil nil nil))) >> >> and your version of `set-file-extended-attributes' would fail when both >> of these fail. > > You mean, a GNU/Linux machine that supports neither ACLs nor SELinux, > I suppose. Do such machines exist, and if so, are they popular? I think that there are still administrators of servers that disable selinux since dealing with it can be a PITA. It's at least something that was popular a few years ago, so I'm guessing that such setups are still used. Also, some quick web grepping got me to https://wiki.debian.org/SELinux which says The Debian packaged Linux kernels have SELinux support compiled in, but disabled by default. ... Please note that SELinux is a Linux-specific feature and Debian packages shouldn't assume it is present >> With my fix, `file-extended-attributes' would just return nil in >> that case, and `set-file-extended-attributes' will succeed >> trivially. > > Why should set-file-extended-attributes succeed in this case? It > didn't set any extended attributes, right? Well, it did set all of the specified attributes, since there were none of them. My new fix above will succeed in this case because it will ignore all of them. > And if neither ACLs nor SELinux is supported, we should definitely > fall back on chmod for the backup files, shouldn't we? But chmod is not done on backup files other than copy the original bits to the backup. (The failure I had with that was for the fallback file.) -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life!