[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Tramp sudoedit method (was: sudo:: method in tramp possible security iss

From: Michael Albinus
Subject: Tramp sudoedit method (was: sudo:: method in tramp possible security issue)
Date: Sun, 16 Dec 2018 16:24:26 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Michael Albinus <address@hidden> writes:


>>> Right, but would it run emacs-lisp code with elevated privileges?
>>> Can't we just make a sudoedit method that just invokes the sudoedit
>>> program or "sudo -e"?  This is what I thought sudo:: did in the first place.
>> All of Tramp basically works by starting an `sh` process (via ssh, sudo,
>> you name it) and then sending it commands to retrieve meta-info about
>> files, contents of file, etc...
> Right. But maybe we could offer a Tramp method "sudoedit", which behaves
> differently. If somebody opens "C-x C-f /sudoedit::/etc/passwd", Tramp
> starts in the background the process "env EDITOR=emacsclient sudoedit
> /etc/passwd" (plus fiddling with `server-start', password handling, and
> alike). Nothing else but just editing the file, and saving it, would be
> possible.
> Don't know what it means for implementation, because visiting a file is
> more than just calling `insert-file-contents'. Handlers for all the
> other magic file operations should return proper results, w/o running a
> shell under root permissions.

I gave it a try. I could make `insert-file-contents' and `write-region'
run based on emacsclient, but it wasn't mature enough. So I have
implemented the "sudoedit" method by applying a respective sudo call for
everything. It isn't using the sudoedit command any longer, but I kept
the method name, because it behaves similar. If it confuses people too
much, we could change the name.

Contrary to the "sudo" method, it is applicable only to the local host,
and it cannot be used in multi-hop methods. Furthermore, it has a worse
performance than "sudo", especially for large directories like "/etc",
visited with `dired'. Maybe this could be improved by a native
implementation of `directory-files-and-attributes' and `insert-directory'.

But it keeps the security promise, not to run a shell in the background
with other user credentials, which could be attacked by malicious code.

Pushed to master. What do people think?

>>         Stefan

Best regards, Michael.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]