The off-list discussion below is about TRAMP's usage of
the /sudo:: method, which surprised me very much recently
because I discovered that it lets any elisp run arbitrary shell
commands with root permissions while the buffer editing a file
with /sudo:: is live.
So in theory you could write malicious elisp code to lay there
hoping to hijack a users system on their first file of
/sudo::/etc/apt/sources.list, for example. Supposing all the user
wanted is to edit that file, starting a full "elisp sudo server" for
the duration of the buffer is clearly overkill and unnecessarily
dangerous for most users.
For me this is a very serious security hole, but apparently
it's part of the contract of the /sudo:: method.
I am arguing for:
1. A sudoedit method that works like `sudo -e`
2. A one-time stern warning the first time that the user uses /sudo::
to explain the security implications to new users.
Michael and I are converging on some possibilities, but I
think it's a good idea to have the rest of emacs-devel speak
[Michael you have my new in-line replies below, too]
On Tue, Nov 20, 2018 at 1:53 PM Michael Albinus <address@hidden
João Távora <address@hidden> writes:
> For the time being, the Tramp manual says:
> --8<---------------cut here---------------start------------->8---
> Similar to ‘su’ method, ‘sudo’ uses ‘sudo’. ‘sudo’ must have
> sufficient rights to start a shell.
> --8<---------------cut here---------------end--------------->8---
> It says already that a shell is used, but perhaps we shall
> emphasize it more. As I said: manuals are unread ...
> Very true, and this is why I am suggesting an in-your-face warning.
That would be bossy. People would start to modify the code in order to
Perhaps I didn't explain myself. I'm talking about a one-time thing, like
the warnings for a disabled command. Something that you can answer
"I understand the risks: never ask for this again".
Once sudoedit is offered by Tramp, I expect a respective recommendation
OK. I believe this is not quite enough. But I'm talking for myself. I think
we should indeed raise the matter publicly.
> And I don't agree it's like sudo -i, because I don't think there is an
> easy way for non-root code running before the sudo -i session to
> inject itself into the root session, or is there? Certainly not as
> easy as writing some trivial elisp.
Everybody is able to write such code. A simple `shell-command' with
"sudo" might suffice to run any command with root permissions. Or use
the interactive `shell', and call "sudo -i" there. Nothing you need
I was just arguing that the comparison between "sudo -i", meant to be
run in a shell and tramp's launching of a "sudo shell" isn't adequate, because
there's no easy way for some unprivileged code to stay around
and wait for an opportunity to hijack your interactive "sudo -i"
> /Sudoedit:: would be a really good addition. It would replace all the
> usage I and quite possibly many others have ever had of /sudo::.
Agreed. If it is possible to implement as proposed.
(Please write the bug report about, in order to discuss it with greater
audience. Or start a discussion at the emacs-devel ML.)
I just did that.