bug#28540: eshell/sudo find-file doesn't work as expected with files only readable by root

bug#28540: eshell/sudo find-file doesn't work as expected with files only readable by root

[Yegor Timoshenko]

To reproduce, M-x eshell and compare behavior of these two commands:

$ ff /sudo::/etc/sudoers
$ sudo ff /etc/sudoers

In the first case the buffer is editable (and can be saved), while in
the latter it is opened read-only. Switching read-only flag with C-x
C-q doesn't help: I can edit the buffer, but not save it (results in
"Doing chmod: operation not permitted" error).

GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars)
 of 2017-09-21 (198ba449845ffa557ac272c3219c703148648f53)

Reproducible in Emacs 25.3 as well.

bug#28540: Acknowledgement (eshell/sudo find-file doesn't work as expected with files only readable by root)

[Yegor Timoshenko]

Sorry, two assumptions in the previous email:

(defalias 'ff 'find-file)
(eval-after-load 'esh-module
  '(add-to-list 'eshell-modules-list 'eshell-tramp))

On Thu, Sep 21, 2017 at 3:26 PM, GNU bug Tracking System
<help-debbugs@gnu.org> wrote:
> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  bug-gnu-emacs@gnu.org
>
> If you wish to submit further information on this problem, please
> send it to 28540@debbugs.gnu.org.
>
> Please do not send mail to help-debbugs@gnu.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 28540: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=28540
> GNU Bug Tracking System
> Contact help-debbugs@gnu.org with problems

bug#28540: eshell/sudo find-file doesn't work as expected with files only readable by root

[Michael Albinus]

Yegor Timoshenko <yegortimoshenko@gmail.com> writes:

Hi Yegor,

[sorry for the late reply; this bug flew under my radar]

> To reproduce, M-x eshell and compare behavior of these two commands:
>
> $ ff /sudo::/etc/sudoers
> $ sudo ff /etc/sudoers
>
> In the first case the buffer is editable (and can be saved), while in
> the latter it is opened read-only. Switching read-only flag with C-x
> C-q doesn't help: I can edit the buffer, but not save it (results in
> "Doing chmod: operation not permitted" error).
>
> GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars)
>  of 2017-09-21 (198ba449845ffa557ac272c3219c703148648f53)
>
> Reproducible in Emacs 25.3 as well.
>
> Sorry, two assumptions in the previous email:
>
> (defalias 'ff 'find-file)
> (eval-after-load 'esh-module
>   '(add-to-list 'eshell-modules-list 'eshell-tramp))

I believe this behavior is correct. In your first test, the file has
been opened as "/sudo::/etc/sudoers". But in the second test, the file
has been opened as "/etc/sudoers" (you will see this, when you try to
pen another file via "C-x C-f": "/etc/" is offered to you as default
directory).

The point is, that the "sudo" command changes the default directory
internally to "/sudo:root@localhost:...", but the following Lisp code
(expanding your alias) evaluates as (find-file "/etc/passwd"). And
although the current default directory is remote, just the local
"/etc/passwd" is opened. And you have no write permissions there.

In order to change this behavior, ehsell would need to analyze the
command given after the leading "sudo". For shell commands like "sudo
*cat /etc/sudoers", the file name must be kept literally, because it is
evalled in the shell command. But for Lisp commands, like your "sudo ff
/etc/sudoers", the file name must be expanded internally to "sudo ff
/sudo::/etc/sudoers".

This requires much knowledge about what a command like "cat" or "ff" is
intended to do. I doubt we will go such far in eshell.

Best regards, Michael.

bug#28540: eshell/sudo find-file doesn't work as expected with files only readable by root

[Stefan Kangas]

tags 28540 + wontfix
close 28540
quit

Michael Albinus <michael.albinus@gmx.de> writes:

> Yegor Timoshenko <yegortimoshenko@gmail.com> writes:
>
> Hi Yegor,
>
> [sorry for the late reply; this bug flew under my radar]
>
>> To reproduce, M-x eshell and compare behavior of these two commands:
>>
>> $ ff /sudo::/etc/sudoers
>> $ sudo ff /etc/sudoers
>>
>> In the first case the buffer is editable (and can be saved), while in
>> the latter it is opened read-only. Switching read-only flag with C-x
>> C-q doesn't help: I can edit the buffer, but not save it (results in
>> "Doing chmod: operation not permitted" error).
>>
>> GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars)
>>  of 2017-09-21 (198ba449845ffa557ac272c3219c703148648f53)
>>
>> Reproducible in Emacs 25.3 as well.
>>
>> Sorry, two assumptions in the previous email:
>>
>> (defalias 'ff 'find-file)
>> (eval-after-load 'esh-module
>>   '(add-to-list 'eshell-modules-list 'eshell-tramp))
>
> I believe this behavior is correct. In your first test, the file has
> been opened as "/sudo::/etc/sudoers". But in the second test, the file
> has been opened as "/etc/sudoers" (you will see this, when you try to
> pen another file via "C-x C-f": "/etc/" is offered to you as default
> directory).
>
> The point is, that the "sudo" command changes the default directory
> internally to "/sudo:root@localhost:...", but the following Lisp code
> (expanding your alias) evaluates as (find-file "/etc/passwd"). And
> although the current default directory is remote, just the local
> "/etc/passwd" is opened. And you have no write permissions there.
>
> In order to change this behavior, ehsell would need to analyze the
> command given after the leading "sudo". For shell commands like "sudo
> *cat /etc/sudoers", the file name must be kept literally, because it is
> evalled in the shell command. But for Lisp commands, like your "sudo ff
> /etc/sudoers", the file name must be expanded internally to "sudo ff
> /sudo::/etc/sudoers".
>
> This requires much knowledge about what a command like "cat" or "ff" is
> intended to do. I doubt we will go such far in eshell.

I agree.  To do this right in general would be a significant
undertaking for a very minor benefit.  I'm therefore closing this as
wontfix.

If anyone disagrees with that, feel free to reopen.

Best regards,
Stefan Kangas