creating backups in temporary directories

creating backups in temporary directories

[Chris Moore]

[-- Attachment #1.1: Type: text/plain, Size: 586 bytes --]

I quite often want to email diffs of files I don't have write access to, so
I visit the file, write it to /tmp, then edit it, save it, and go to /tmp to
run diff between the file and its backup.  But Emacs doesn't make backups of
files in /tmp, and there doesn't seem to be any way of asking it to via the
customize interface.

The best I've found is to:
  (setq backup-enable-predicate '(lambda (file) t))



Suggestions:
1) make that the default value - why not write backups in /tmp?
2) offer a way for the user to customize the behavior without resorting to
writing Emacs LISP code

[-- Attachment #1.2: Type: text/html, Size: 649 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: creating backups in temporary directories

[David Kastrup]

"Chris Moore" <christopher.ian.moore@gmail.com> writes:

> I quite often want to email diffs of files I don't have write access
> to, so I visit the file, write it to /tmp, then edit it, save it,
> and go to /tmp to run diff between the file and its backup.

That's not what backups are for.  Why don't you save under a different
name?  That's what C-x C-w is for.

> Suggestions:
> 1) make that the default value - why not write backups in /tmp?

Because making a "backup" for a file in a place that is regularly
cleaned out is creating an illusion of security.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: creating backups in temporary directories

[Stefan Monnier]

>> I quite often want to email diffs of files I don't have write access
>> to, so I visit the file, write it to /tmp, then edit it, save it,
>> and go to /tmp to run diff between the file and its backup.

> That's not what backups are for.  Why don't you save under a different
> name?  That's what C-x C-w is for.

>> Suggestions:
>> 1) make that the default value - why not write backups in /tmp?

> Because making a "backup" for a file in a place that is regularly
> cleaned out is creating an illusion of security.

Worse yet: creating backup files in /tmp would be a security hole:
some other user seeing you're currently editing /tmp/foo could create
a symlink /tmp/foo~ to some interesting place and then when you save your
file the backup could be placed at that interesting place chosen by
the attacker.


        Stefan

Re: creating backups in temporary directories

[Davis Herring]

>> Because making a "backup" for a file in a place that is regularly
>> cleaned out is creating an illusion of security.
>
> Worse yet: creating backup files in /tmp would be a security hole:
> some other user seeing you're currently editing /tmp/foo could create
> a symlink /tmp/foo~ to some interesting place and then when you save your
> file the backup could be placed at that interesting place chosen by
> the attacker.

That could be avoided by unconditionally backing up by renaming in that
case, I suppose.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: creating backups in temporary directories

[Sven Joachim]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Suggestions:
>>> 1) make that the default value - why not write backups in /tmp?
>
>> Because making a "backup" for a file in a place that is regularly
>> cleaned out is creating an illusion of security.
>
> Worse yet: creating backup files in /tmp would be a security hole:
> some other user seeing you're currently editing /tmp/foo could create
> a symlink /tmp/foo~ to some interesting place and then when you save your
> file the backup could be placed at that interesting place chosen by
> the attacker.

Really?  I've just tried this (with a symlink in ~/tmp instead of
/tmp), and Emacs removed the symlink for the backup before saving the
file.  Are there circumstances where it might not do this?

Re: creating backups in temporary directories

[David Kastrup]

Sven Joachim <svenjoac@gmx.de> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Worse yet: creating backup files in /tmp would be a security hole:
>> some other user seeing you're currently editing /tmp/foo could
>> create a symlink /tmp/foo~ to some interesting place and then when
>> you save your file the backup could be placed at that interesting
>> place chosen by the attacker.
>
> Really?  I've just tried this (with a symlink in ~/tmp instead of
> /tmp), and Emacs removed the symlink for the backup before saving
> the file.  Are there circumstances where it might not do this?

Can you spell "race condition"?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: creating backups in temporary directories

[Stefan Monnier]

> Really?  I've just tried this (with a symlink in ~/tmp instead of
> /tmp), and Emacs removed the symlink for the backup before saving the
> file.  Are there circumstances where it might not do this?

IIUC this depends on backup-by-copying.  If backup-by-copying is nil, then
the problem is indeed not present, but you get another one insted: right
after Emacs moves /tmp/foo to /tmp/foo~ another user can add a symlink
/tmp/foo that points to an interesting place and then when Emacs
subsequently writes the new /tmp/foo it gets written to the location chosen
by the attacker.


        Stefan

Re: creating backups in temporary directories

[Chris Moore]

[-- Attachment #1.1: Type: text/plain, Size: 1051 bytes --]

On 9/7/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> Worse yet: creating backup files in /tmp would be a security hole:
> some other user seeing you're currently editing /tmp/foo could create
> a symlink /tmp/foo~ to some interesting place and then when you save your
> file the backup could be placed at that interesting place chosen by
> the attacker.


If that is the case, then that is an argument for not backing backups in any
world (or group?) writeable place.  It's not specific to /tmp.

I often work in /tmp/ on files that I know I won't want to keep.  I still
find backup files useful, even for these temporary files.  Yes, I can use
C-x C-w instead, but that's something I have to remember to do each time,
*before* I start editing, otherwise it's too late.  I find it a lot more
convenient to have Emacs automatically make backup files, and think it would
be good to have a user-configurable option to do so.  Not that it matters to
me personally, I can put some magic Emacs Lisp in my .emacs to get the
effect I want.

Chris.

[-- Attachment #1.2: Type: text/html, Size: 1451 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: creating backups in temporary directories

[Richard Stallman]

    > Really?  I've just tried this (with a symlink in ~/tmp instead of
    > /tmp), and Emacs removed the symlink for the backup before saving
    > the file.  Are there circumstances where it might not do this?

    Can you spell "race condition"?

A couple of weeks ago we were discussing the code in backup-buffer-copy
that deals with deleting files.  The motive for that code may have
been an attempt to address this problem.  But it may not really solve
the problem.  Can we solve it there?

Re: creating backups in temporary directories

[Richard Stallman]

    IIUC this depends on backup-by-copying.  If backup-by-copying is nil, then
    the problem is indeed not present, but you get another one insted: right
    after Emacs moves /tmp/foo to /tmp/foo~ another user can add a symlink
    /tmp/foo that points to an interesting place and then when Emacs
    subsequently writes the new /tmp/foo it gets written to the location chosen
    by the attacker.

I think we can't do anything to get rid of that problem.
Writing thru symlinks is an important feature; if other people
can create the symlink, it follows inevitably that they could do this.

Re: creating backups in temporary directories

[Richard Stallman]

    Worse yet: creating backup files in /tmp would be a security hole:
    some other user seeing you're currently editing /tmp/foo could create
    a symlink /tmp/foo~ to some interesting place and then when you save your
    file the backup could be placed at that interesting place chosen by
    the attacker.

Is that equally true for any directory that others can write?

Re: creating backups in temporary directories

[Stefan Monnier]

>     Worse yet: creating backup files in /tmp would be a security hole:
>     some other user seeing you're currently editing /tmp/foo could create
>     a symlink /tmp/foo~ to some interesting place and then when you save your
>     file the backup could be placed at that interesting place chosen by
>     the attacker.

> Is that equally true for any directory that others can write?

Yes.


        Stefan

Re: creating backups in temporary directories

[Stefan Monnier]

>     IIUC this depends on backup-by-copying.  If backup-by-copying is nil,
>     then the problem is indeed not present, but you get another one
>     insted: right after Emacs moves /tmp/foo to /tmp/foo~ another user can
>     add a symlink /tmp/foo that points to an interesting place and then
>     when Emacs subsequently writes the new /tmp/foo it gets written to the
>     location chosen by the attacker.

> I think we can't do anything to get rid of that problem.

I'd tend to agree.

> Writing thru symlinks is an important feature;

Very much so.

> if other people can create the symlink, it follows inevitably that they
> could do this.

In a directory with mode 777, that's true: everything is dangerous.
But in a directory with mode 1777 when you open a file that *you* own,
nobody else can remove it or rename it, so normally nobody can replace it
with a symlink.  Emacs creates the problem when it moves /tmp/foo to
/tmp/foo~ at which point /tmp/foo is free for an attacker to take.


        Stefan

Re: creating backups in temporary directories

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>     Worse yet: creating backup files in /tmp would be a security hole:
>>     some other user seeing you're currently editing /tmp/foo could create
>>     a symlink /tmp/foo~ to some interesting place and then when you save your
>>     file the backup could be placed at that interesting place chosen by
>>     the attacker.
>
>> Is that equally true for any directory that others can write?
>
> Yes.

Well, there is sort of a difference: /tmp and similar are
world-writable because of technical reasons.  Other directories might
be accessible to more than one person (usually group-accessible)
creating an explicit location for cooperation.  So malicious attacks
are not as much anticipated there, also because they are not generally
available (/tmp and /var/tmp are on pretty much every system).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: creating backups in temporary directories

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> In a directory with mode 777, that's true: everything is dangerous.
> But in a directory with mode 1777 when you open a file that *you* own,
> nobody else can remove it or rename it, so normally nobody can replace it
> with a symlink.  Emacs creates the problem when it moves /tmp/foo to
> /tmp/foo~ at which point /tmp/foo is free for an attacker to take.

Well, the alternative is to make a hard link of /tmp/foo to /tmp/foo~,
then creat /tmp/foo over it and fill it with contents without
reopening.

That should close the time window for an attack.

Anyway, using O_CREAT|O_EXCL when opening refuses to go through
symbolic links.

So we should have a few options available for avoiding problems.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: creating backups in temporary directories

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> In a directory with mode 777, that's true: everything is dangerous.
>> But in a directory with mode 1777 when you open a file that *you* own,
>> nobody else can remove it or rename it, so normally nobody can replace it
>> with a symlink.  Emacs creates the problem when it moves /tmp/foo to
>> /tmp/foo~ at which point /tmp/foo is free for an attacker to take.
>
> Well, the alternative is to make a hard link of /tmp/foo to /tmp/foo~,
> then creat /tmp/foo over it and fill it with contents without
> reopening.
>
> That should close the time window for an attack.

You have to unlink the file first, so the window remains.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: creating backups in temporary directories

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>>> In a directory with mode 777, that's true: everything is dangerous.
>>> But in a directory with mode 1777 when you open a file that *you* own,
>>> nobody else can remove it or rename it, so normally nobody can replace it
>>> with a symlink.  Emacs creates the problem when it moves /tmp/foo to
>>> /tmp/foo~ at which point /tmp/foo is free for an attacker to take.
>>
>> Well, the alternative is to make a hard link of /tmp/foo to /tmp/foo~,
>> then creat /tmp/foo over it and fill it with contents without
>> reopening.
>>
>> That should close the time window for an attack.
>
> You have to unlink the file first,

Well, seems I misread the manual page for open/creat.  I thought that
without O_EXCL, the file would get replaced.

Well, then there still is the contorted way of hard linking /tmp/foo
to /tmp/foo~, opening /tmp/randomfilename for write, renaming it to
/tmp/foo and then finishing the write operation.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: creating backups in temporary directories

[Richard Stallman]

    >     Worse yet: creating backup files in /tmp would be a security hole:
    >     some other user seeing you're currently editing /tmp/foo could create
    >     a symlink /tmp/foo~ to some interesting place and then when you save your
    >     file the backup could be placed at that interesting place chosen by
    >     the attacker.

    > Is that equally true for any directory that others can write?

    Yes.

This means that the practice of not making backup files in /tmp
is not a solution for the problem.

Is there any solution?

(I think the motive for not making backup files in /tmp
was just that it seemed pointless.)

Re: creating backups in temporary directories

[Richard Stallman]

    But in a directory with mode 1777 when you open a file that *you* own,
    nobody else can remove it or rename it, so normally nobody can replace it
    with a symlink.  Emacs creates the problem when it moves /tmp/foo to
    /tmp/foo~ at which point /tmp/foo is free for an attacker to take.

This suggests that Emacs should always do backup by copying
in such directories.  Would that solve the problem?

Re: creating backups in temporary directories

[Stefan Monnier]

>     But in a directory with mode 1777 when you open a file that *you* own,
>     nobody else can remove it or rename it, so normally nobody can replace it
>     with a symlink.  Emacs creates the problem when it moves /tmp/foo to
>     /tmp/foo~ at which point /tmp/foo is free for an attacker to take.

> This suggests that Emacs should always do backup by copying
> in such directories.  Would that solve the problem?

It replaces one problem by another.  More specifically, it's safe to do
a backup using copying on one condition: that there was already a backup
(owned by you).  Otherwise, we bump into the problem I mentioned originally:
some other user could see you're editing /tmp/foo and create a /tmp/foo~
symlink before you create it.


        Stefan

Re: creating backups in temporary directories

[Davis Herring]

> Well, seems I misread the manual page for open/creat.  I thought that
> without O_EXCL, the file would get replaced.
>
> Well, then there still is the contorted way of hard linking /tmp/foo
> to /tmp/foo~, opening /tmp/randomfilename for write, renaming it to
> /tmp/foo and then finishing the write operation.

Why not just rename /tmp/foo to /tmp/foo~, then open /tmp/foo with O_EXCL?
 If it fails, then write (again with O_EXCL) to /tmp/randomfile so that
the user's work is on disk -somewhere-, and tell them that they have
enemies.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: creating backups in temporary directories

[Davis Herring]

I wrote:

>> Well, then there still is the contorted way of hard linking /tmp/foo
>> to /tmp/foo~, opening /tmp/randomfilename for write, renaming it to
>> /tmp/foo and then finishing the write operation.
>
> Why not just rename /tmp/foo to /tmp/foo~, then open /tmp/foo with O_EXCL?
>  If it fails, then write (again with O_EXCL) to /tmp/randomfile so that
> the user's work is on disk -somewhere-, and tell them that they have
> enemies.

This of course applies to the backup-by-copying case too: then just open
/tmp/foo~ with O_EXCL when performing the copy, with /tmp/randomfile~ and
"you have enemies" if it fails.

If /tmp/foo~ already exists, rename it first to /tmp/backupforthebackup~
rather than unlinking it; we have to get it out of the way and use O_EXCL
even if we own it in case the directory's owner is the attacker.  (We
don't want to unlink it because getting rid of the backup before we start
writing the new one is unnecessarily fragile.)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: creating backups in temporary directories

[David Kastrup]

"Davis Herring" <herring@lanl.gov> writes:

>> Well, seems I misread the manual page for open/creat.  I thought that
>> without O_EXCL, the file would get replaced.
>>
>> Well, then there still is the contorted way of hard linking /tmp/foo
>> to /tmp/foo~, opening /tmp/randomfilename for write, renaming it to
>> /tmp/foo and then finishing the write operation.
>
> Why not just rename /tmp/foo to /tmp/foo~, then open /tmp/foo with O_EXCL?
>  If it fails, then write (again with O_EXCL) to /tmp/randomfile so that
> the user's work is on disk -somewhere-, and tell them that they have
> enemies.

I would simply not save at all if O_EXCL fails, leave the buffer
marked as modified, and set a buffer-permanent local variable
save-only-when-nonexistent to buffer-filename.  Attempts to save the
buffer to a file with the filename save-only-when-nonexistent will use
O_EXCL.

Auto save files should always be opened O_EXCL.

When a file lock for a non-existing file is created,
save-only-when-nonexistent is set at the same time.  Hm, this is sort
of a mess.  There will always be somewhat predictable names on /tmp
and similar.  Perhaps we should have some rule not to write through
symlinks in such directories after all.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: creating backups in temporary directories

[Richard Stallman]

    This of course applies to the backup-by-copying case too: then just open
    /tmp/foo~ with O_EXCL when performing the copy, with /tmp/randomfile~ and
    "you have enemies" if it fails.

The code in backup-buffer-copy already does part of this;
it calls copy-file  in a way that uses O_EXCL.

    If /tmp/foo~ already exists, rename it first to /tmp/backupforthebackup~
    rather than unlinking it; we have to get it out of the way and use O_EXCL
    even if we own it in case the directory's owner is the attacker.

Why is this needed?  When we're doing the copy, the actual source file
also exists.

Re: creating backups in temporary directories

[Davis Herring]

> The code in backup-buffer-copy already does part of this;
> it calls copy-file  in a way that uses O_EXCL.

Ah.  That's good; I was trying to provide a self-contained concept rather
than a patch, if you take my meaning.

>     If /tmp/foo~ already exists, rename it first to
> /tmp/backupforthebackup~
>     rather than unlinking it; we have to get it out of the way and use
> O_EXCL
>     even if we own it in case the directory's owner is the attacker.
>
> Why is this needed?  When we're doing the copy, the actual source file
> also exists.

(By "this" you must mean the rename instead of the unlink; I trust that
the reason for having to do one or the other was understood.)  I guess
it's not actually necessary.  I was thinking it would be better to reduce
the amount of time when there was no backup; but at this point the user
wants the current contents of the actual file to _become_ the backup, so
the existing backup is completely expendable.  (Of course, it gets more
complicated with numbered backups...)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.