|
From: | Paul Eggert |
Subject: | bug#27986: 26.0.50; 'rename-file' can rename files without confirmation |
Date: | Tue, 15 Aug 2017 22:06:38 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 |
Eli Zaretskii wrote:
Knowing how Emacs works is not enough: they need to actually know the name of the directory to create,
By "knowing how Emacs works" I meant all of Emacs, including the Lisp program that it is running. We cannot rely on security-via-obscurity; we must assume that the attackers know not only the Emacs C source code, but the Lisp code that Emacs runs. Such an attacker will know the name of the directory to create.
And how is this case different from the case that Emacs calls (rename-file A B) thinking B doesn't exist (e.g., because some prior code tested that)?The case in question trashes a directory that the attacker lacks permission to. The case you're talking about does not: it merely causes rename-file to fail.No, it's the same use case. In both of them the attacker creates a directory ahead of Emacs using it in some system call.
Sure, but in the use case I'm talking about, the attacker can trash the victim's directory even though it's write-protected. In the case you're talking about, the attacker can't do anything other than what the attacker could do already.
Another possibility is to implement new functions (say: file-copy, file-rename, file-link, file-symlink, and directory-copy) that behave like the existing functions except without the security hole, modify callers to use these new functions, and then mark the existing functions as deprecated due to security concerns.If no other solution is possible, maybe this is what we should do. If we decide to go that way, we should also decide what to do with the interactive use of those functions: whether to call the old or the new variant, because we need to keep backward compatibility there as well.
I don't see why. If a user calls M-x copy-file interactively they'll get the old function; if they call M-x file-copy they'll get the new one. Admittedly there will be confusion (see below).
I suspect that this would be more disruptive overall than the proposed change, though (albeit disruptive in a different way).How so?
It'll be disruption caused by the extra complexity: pairs of functions that do nearly the same thing, with user confusion over which function to call, and people calling the wrong one. Tramp will need at least four new methods to support, probably more. The complexity and confusion will go on and on, and will cost more than will be saved by the backward compatibility. It would be worth all this trouble if people needed the old behavior, but they mostly do not.
[Prev in Thread] | Current Thread | [Next in Thread] |