Re: master 739593d 3/5: Make gnus-copy-file act like copy-file etc.

[Lars Ingebrigtsen <larsi@gnus.org>]

Paul Eggert <eggert@cs.ucla.edu> writes:

> If the attacker knows what the user is up to (and this can be guessed
> often enough by looking at what Emacs has done to the file system
> recently), the attacker can hijack the rename. For example, if you
> type 'M-x rename-file RET abc RET /tmp/def RET', the attacker can
> create a symlink /tmp/def to a victim directory D so that the file abc
> is moved to D/abc rather than to its intended location /tmp/def.

Hm...  I see...

> This attack can happen only when the destination's parent directory
> (/tmp in the above example) is writable to the attacker. So we could
> bring back support for interactive renames to destination directories
> whose parents are writable only by self or root.

The attack surface you're trying to cover is when the user is writing a
file to a world-writable directory that contains a symlink that has
exactly the same name as the file you're trying to write?

Altering Emacs' way of renaming/copying/saving files everywhere for just
this single (and extremely unlikely) attack seems rather misguided, in
my opinion.  If we want to protect against that case, then we should
instead revert all the changes you've made to these functions and
introduce a new

(barf-if-you're-writing-a-file-with-the-same-name-to-a-symlink-in-a-world-writable-directory FILE)

function that we can slap into the affected functions and leave the
interactive parts working as they have always.

These days nobody lives on shared computers, anyway, so crippling these
common interactive commands to protect against non-existent people
making symlinks in /tmp does not seem like a good idea to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no