unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Jim Meyering <jim@meyering.net>
Cc: Emacs development discussions <emacs-devel@gnu.org>
Subject: Re: save-buffer: avoid data loss on interrupt
Date: Wed, 14 Dec 2011 10:51:57 -0800	[thread overview]
Message-ID: <4EE8F04D.8060007@cs.ucla.edu> (raw)
In-Reply-To: <87fwgnp672.fsf@rho.meyering.net>

On 12/14/11 06:40, Jim Meyering wrote:

> I can add a test for the presence of an ACL,
> and handle that just like a hard link count of 2 or greater:
> resort to the standard, non-atomic code path.

Yes, but then my reward for trying to be safer and using an ACL
is that my file's contents are more likely to get lost.  Ouch.

Plus, it's not as simple as looking for an ACL on the original
file.  One must also look for ACLs that might be inherited by
the newly created copy.

> If the cost of an extra stat is not prohibitive, I'm
> tempted to keep this change simple, check for a set-UID
> parent directory

I'm afraid it's not as simple as that.  Not only must
the parent directory be setuid, but the file system needs
to be mounted with the suiddir option.  Not all file systems
support that option; some silently ignore it.

And won't we have a problem there with network file systems?
It's not clear to me whether the setuid semantics are
specified by the client OS or the server OS.  (Likewise
for ACLs inherited by the new file.)

All in all, I think that in the long run it'll be simpler and
more reliable if we create the temp file and then check
that it has (or make it have) the correct ownership and permissions.



  reply	other threads:[~2011-12-14 18:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-09 10:26 enabling atomic-update more often, i.e., rewrite via rename Jim Meyering
2011-12-13 17:13 ` save-buffer: avoid data loss on interrupt Jim Meyering
2011-12-13 20:03   ` Paul Eggert
2011-12-13 20:52     ` Jim Meyering
2011-12-13 21:47       ` Paul Eggert
2011-12-13 22:27         ` chad
2011-12-14 14:40         ` Jim Meyering
2011-12-14 18:51           ` Paul Eggert [this message]
2011-12-15 23:53             ` Stefan Monnier
2011-12-14  2:40   ` Stefan Monnier
2011-12-15 12:58   ` Jim Meyering

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=4EE8F04D.8060007@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=emacs-devel@gnu.org \
    --cc=jim@meyering.net \
    /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).