unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: romain@orebokech.com, emacs-devel@gnu.org
Subject: Re: set-file-extended-attributes and backups
Date: Fri, 21 Dec 2012 10:31:30 -0800	[thread overview]
Message-ID: <50D4AB02.4000203@cs.ucla.edu> (raw)
In-Reply-To: <837gobqnvy.fsf@gnu.org>

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.



  reply	other threads:[~2012-12-21 18:31 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-21 14:53 set-file-extended-attributes and backups Eli Zaretskii
2012-12-21 16:00 ` Paul Eggert
2012-12-21 16:44   ` Eli Zaretskii
2012-12-21 17:48     ` Paul Eggert
2012-12-21 18:08       ` Eli Zaretskii
2012-12-21 18:31         ` Paul Eggert [this message]
2012-12-23 16:59     ` Romain Francoise
2012-12-23 17:35       ` Eli Zaretskii
2012-12-24  0:59         ` Stefan Monnier
2012-12-24  3:44           ` Eli Zaretskii
2012-12-24  5:18             ` Stefan Monnier
2012-12-24  8:25               ` Michael Albinus
2012-12-24 16:24               ` Eli Zaretskii
2012-12-21 18:31 ` Romain Francoise
2012-12-22 23:03   ` Fabrice Popineau
2012-12-23  3:54     ` Eli Zaretskii
2012-12-23 17:17       ` Eli Zaretskii
2012-12-22 16:05 ` Stefan Monnier
2012-12-22 17:03   ` Eli Zaretskii
2012-12-23 13:37     ` Stefan Monnier
2012-12-29 17:20       ` Eli Zaretskii
2012-12-29 17:50         ` Eli Zaretskii
2012-12-29 19:12           ` Michael Albinus
2012-12-30 10:59             ` Michael Albinus
2012-12-30 17:21               ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50D4AB02.4000203@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=romain@orebokech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).