From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: set-file-extended-attributes and backups Date: Fri, 21 Dec 2012 10:31:30 -0800 Message-ID: <50D4AB02.4000203@cs.ucla.edu> References: <83obhntq1m.fsf@gnu.org> <50D48781.1050303@cs.ucla.edu> <83a9t7qrrw.fsf@gnu.org> <50D4A0E4.3050004@cs.ucla.edu> <837gobqnvy.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1356114716 30431 80.91.229.3 (21 Dec 2012 18:31:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Dec 2012 18:31:56 +0000 (UTC) Cc: romain@orebokech.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 21 19:32:11 2012 Return-path: Envelope-to: ged-emacs-devel@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 1Tm7OC-0005vY-1a for ged-emacs-devel@m.gmane.org; Fri, 21 Dec 2012 19:32:08 +0100 Original-Received: from localhost ([::1]:50080 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tm7Ny-0007Sm-Ag for ged-emacs-devel@m.gmane.org; Fri, 21 Dec 2012 13:31:54 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:59542) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tm7Nq-0007Se-Ko for emacs-devel@gnu.org; Fri, 21 Dec 2012 13:31:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tm7Ni-0006Kh-Vf for emacs-devel@gnu.org; Fri, 21 Dec 2012 13:31:46 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:34121) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tm7Nc-0006GN-MT; Fri, 21 Dec 2012 13:31:32 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 5B74839E8108; Fri, 21 Dec 2012 10:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IW2GhLzpjij; Fri, 21 Dec 2012 10:31:30 -0800 (PST) Original-Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id D401239E8105; Fri, 21 Dec 2012 10:31:30 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: <837gobqnvy.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 131.179.128.62 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:155742 Archived-At: On 12/21/12 10:08, Eli Zaretskii wrote: > But we did that until a week ago. True, but we're trying to do the right thing with ACLs now, rather than ignore them and do the wrong thing. > this decision should be left to the user, i.e. be a user option. Possibly, but the default should be safe, i.e., it shouldn't grant access rights that were not already there. > So what you ask is > whether the default ACLs will allow some access that a specific ACLs > won't. And the answer to that is "it depends ..." Yes, and the question is whether it's easy to find out all the dependencies, so that Emacs can tell whether the default ACLs would allow any access that the correct ACLs would deny. My guess is that the answer is "no", unfortunately. >> The simplest conservative approximation that I can think of offhand >> is to test whether a file has any nontrivial ACLs. > > That's not good enough, I think: if the nontrivial ACLs specify the > same group as the file's group, the modes and the ACLs are equivalent, > although the ACLs are "nontrivial". Sure, but here it's OK from a security point of view to use a conservative approximation, i.e., a test that sometimes says "yes" even when the true answer is "no". The only downside is that when the conservative approximation is incorrect, then when the ACLs cannot be copied the file will end up in mode -rw-------. That's annoying, but it's safe and I hope it's rare. > That assumes that -rw------- is secure. But that assumption is false, > because ACLs can be more restrictive than that, even on Posix > platforms. No, because if an attacker can read and write a file with permissions -rw-------, then the attacker owns the file (or is superuser) and can change its ACLs. ACLs cannot stop such an attacker. So long as Emacs doesn't grant permissions to anybody other than the owner, Emacs is not giving any secrets away that aren't being given away already. As a minor nicety, we could use mode ----------, if we prefer being safer in an advisory sense. Mode ---------- won't stop an attacker who is the owner, but it would be more likely to prevent blundering owners from shooting themselves in the foot.