bug#27169: eshell/sudo doesn't work with protected directories

bug#27169: eshell/sudo doesn't work with protected directories

[Yegor Timoshenko]

Example (In M-x eshell):

cd /tmp
mkdir a
touch a/b
sudo chmod 700 a
sudo chown root:wheel a
sudo ls a

Expected output:

b

Instead I get:

/bin/ls: cannot open directory 'a': Permission denied

sudo cat a/b, etc. also don't work. I've found this problem while trying to cat my /etc/sudoers file:

$ sudo cat /etc/sudoers
Opening input file: Permission denied, /etc/sudoers

bug#27169: eshell/sudo doesn't work with protected directories

[npostavs]

tags 27169 unreproducible
quit

Yegor Timoshenko <yegortimoshenko@gmail.com> writes:

> Expected output:
>
> b
>
> Instead I get:
>
> /bin/ls: cannot open directory 'a': Permission denied
>
> sudo cat a/b, etc. also don't work. I've found this problem while trying to cat my /etc/sudoers file:
>
> $ sudo cat /etc/sudoers
> Opening input file: Permission denied, /etc/sudoers

Works for me, can you reproduce this from 'emacs -Q'?  What Emacs
version are you using?

    Welcome to the Emacs shell

    ~/src $ cd /tmp
    /tmp $ mkdir a
    /tmp $ touch a/b
    /tmp $ sudo chmod 700 a
    [sudo] password for npostavs: 
    /tmp $ sudo chown root:wheel a
    [sudo] password for npostavs: 
    /tmp $ sudo ls a
    [sudo] password for npostavs: 
    b
    /tmp $ 

bug#27169: eshell/sudo doesn't work with protected directories

[Yegor Timoshenko]

> Works for me, can you reproduce this from 'emacs -Q'?  What Emacs
> version are you using?

GNU Emacs 25.2.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1911)) of 2017-04-21

Yes, it's reproducible with -Q flag, provided that you execute (require 'em-tramp) in *scratch* buffer.

I believe it can be a platform-specific bug (I use macOS). Patched old Emacs version bundled with my system
(Emacs 22) doesn't have this bug. I've also just built Emacs 25.2 from scratch (using Gentoo Prefix) and tried it with
`emacs -Q` and it is still reproducible:

~ $ cd /tmp
/tmp $ sudo ls a/b
/Users/yegortimoshenko/Documents/Gentoo/bin/ls: cannot access 'a/b': Permission\
denied
/tmp $ emacs-version
GNU Emacs 25.2.1 (x86_64-apple-darwin16, NS appkit-1504.83 Version 10.12.5 (Bui\
ld 16F73))
of 2017-06-07

The same applies to bug#27167.

bug#27169: eshell/sudo doesn't work with protected directories

[npostavs]

[-- Attachment #1: Type: text/plain, Size: 476 bytes --]

tags 27169 = patch
quit

Yegor Timoshenko <yegortimoshenko@gmail.com> writes:

> GNU Emacs 25.2.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1911)) of 2017-04-21
>
> Yes, it's reproducible with -Q flag, provided that you execute (require 'em-tramp) in *scratch* buffer.

Hmm, for some reason that doesn't work for me (possibly another bug),
but if I use 'eshell/sudo' instead of plain 'sudo' I can reproduce your problem.

The following fixes it:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 1459 bytes --]

From e3d96af45b85a9ed9b96a12cae3e68eb21a2de47 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Wed, 7 Jun 2017 18:48:39 -0400
Subject: [PATCH v1] Let eshell/sudo handle absolute command names (Bug#27167)

* lisp/eshell/esh-ext.el (eshell-find-interpreter): Don't change
absolute paths into relative ones.
---
 lisp/eshell/esh-ext.el | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/lisp/eshell/esh-ext.el b/lisp/eshell/esh-ext.el
index fb1fedc9c5..2a495225dc 100644
--- a/lisp/eshell/esh-ext.el
+++ b/lisp/eshell/esh-ext.el
@@ -299,11 +299,13 @@ (defun eshell-find-interpreter (file args &optional no-examine-p)
       (let ((fullname (if (file-name-directory file) file
 			(eshell-search-path file)))
 	    (suffixes eshell-binary-suffixes))
-	(if (and fullname
-		 (not (file-remote-p fullname))
-		 (file-remote-p default-directory))
-	    (setq fullname (expand-file-name
-			    (concat "./" fullname) default-directory)))
+	(when (and fullname
+                   (not (file-remote-p fullname))
+                   (file-remote-p default-directory))
+          (setq fullname
+                (if (file-name-absolute-p fullname)
+                    (concat (file-remote-p default-directory) fullname)
+                  (expand-file-name fullname default-directory))))
 	(if (and fullname (not (or eshell-force-execution
 				   (file-executable-p fullname))))
 	    (while suffixes
-- 
2.11.1

bug#27169: eshell/sudo doesn't work with protected directories

[npostavs]

Yegor Timoshenko <yegortimoshenko@gmail.com> writes:

>> Works for me, can you reproduce this from 'emacs -Q'?  What Emacs
>> version are you using?
>
> GNU Emacs 25.2.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1911)) of 2017-04-21
>
> Yes, it's reproducible with -Q flag, provided that you execute (require 'em-tramp) in *scratch* buffer.

Don't you also need (push 'eshell-tramp eshell-modules-list)?

Once I do that, I'm able to reproduce #27167, but not this bug:

    ~/src $ sudo /bin/cat foo
    /sudo:root@localhost:/home/npostavs/src/bin/cat: command not found
    ~/src $ cd /tmp
    /tmp $ sudo ls a/b
    a/b

> I believe it can be a platform-specific bug (I use macOS).

Possible.  Does this work from M-x shell?  Does C-x C-f /sudo::/tmp/a/
work?  Does it make a difference if you run from the terminal vs running
graphically (there's at least one macOS bug where this makes a
difference, #21573).

bug#27169: eshell/sudo doesn't work with protected directories

[Yegor Timoshenko]

> Don't you also need (push 'eshell-tramp eshell-modules-list)?

I never did that and it seemed to work fine (I had to manually alias
sudo to eshell/sudo, though). Hopefully this will fix some other
problems with eshell I had recently, but adding 'eshell-tramp to
eshell-modules-list didn't resolve the issue.

> Does this work from M-x shell?

No, this one is specific to eshell (actually, to em-tramp eshell/sudo).

> Does C-x C-f /sudo::/tmp/a/ work?

It works.

> Does it make a difference if you run from the terminal vs running
> graphically (there's at least one macOS bug where this makes a
> difference, #21573).

It is reproducible both in graphical and terminal environments.

bug#27169: eshell/sudo doesn't work with protected directories

[npostavs]

Yegor Timoshenko <yegortimoshenko@gmail.com> writes:

>> Don't you also need (push 'eshell-tramp eshell-modules-list)?
>
> I never did that and it seemed to work fine (I had to manually alias
> sudo to eshell/sudo, though).

Aha, that explains it.

>> Does this work from M-x shell?
>
> No, this one is specific to eshell (actually, to em-tramp
> eshell/sudo).

So by "No" you mean "Yes" (it works)? ;)

>> Does C-x C-f /sudo::/tmp/a/ work?
>
> It works.
>
>> Does it make a difference if you run from the terminal vs running
>> graphically (there's at least one macOS bug where this makes a
>> difference, #21573).
>
> It is reproducible both in graphical and terminal environments.

Hmm, if you step through eshell-plain-command does it call
eshell-lisp-command or eshell-external-command to run "ls"?  (for me it
goes through eshell-lisp-command)

bug#27168: bug#27169: eshell/sudo doesn't work with protected directories

[Lars Ingebrigtsen]

npostavs@users.sourceforge.net writes:

>>> Does this work from M-x shell?
>>
>> No, this one is specific to eshell (actually, to em-tramp
>> eshell/sudo).
>
> So by "No" you mean "Yes" (it works)? ;)

Reading this thread, it seems like Noam was unable to reproduce this
bug.  I've tried the given recipe, but I'm not able to reproduce it
either (on Macos Catalina).

Yegor, are you still seeing this problem?  If so, do you have a complete
recipe?

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

bug#27168: bug#27169: eshell/sudo doesn't work with protected directories

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Reading this thread, it seems like Noam was unable to reproduce this
> bug.  I've tried the given recipe, but I'm not able to reproduce it
> either (on Macos Catalina).
>
> Yegor, are you still seeing this problem?  If so, do you have a complete
> recipe?

This was four weeks ago, and there was no response, so I'm closing this
bug report.  If this is still an issue, please respond to the debbugs
address and we'll reopen the report.

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