bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Cray Elliott]

For example, if you went to eshell and typed 'sudo rm -rf /opt/folder'
it would complain about permissions being needed and wouldn't query
for password. Bug doesn't exist with relative paths. Bug does exist with wildcards.


In GNU Emacs 24.0.95.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10)
 of 2012-04-07 on rbdash
Windowing system distributor `The X.Org Foundation', version 11.0.11104000
Configured using:
 `configure '--prefix=/usr' '--sysconfdir=/etc' '--localstatedir=/var'
 '--libexecdir=/usr/lib' '--mandir=/usr/share/man' '--without-sound'
 '--with-xft' '--with-x-toolkit=gtk' 'CFLAGS=-march=x86-64
 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4
 -D_FORTIFY_SOURCE=2'
 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: 
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  evil-mode: t
  evil-local-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  shell-dirtrack-mode: t
  global-auto-complete-mode: t
  auto-complete-mode: t
  diff-auto-refine-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-x C-b C-x 1 M-x r e p o <tab> r t - e m <tab> b <backspace> 
<return>

Recent messages:
("emacs")
Loading "/home/cray/.emacs.d/byte-cache/home!cray!.emacs.d!el-get!color-theme!themes!color-theme-example.elc" as "/home/cray/.emacs.d/el-get/color-theme/themes/color-theme-example.el"...done
Loading "/home/cray/.emacs.d/byte-cache/home!cray!.emacs.d!el-get!color-theme!themes!color-theme-library.elc" as "/home/cray/.emacs.d/el-get/color-theme/themes/color-theme-library.el"...done
ad-handle-definition: `evil-mode' got redefined [38 times]
Starting Emacs daemon.
When done with this frame, type C-x 5 0
Making completion list...

Load-path shadows:
/home/cray/.emacs.d/el-get/dired-plus/dired+ hides /home/cray/.emacs.d/el-get/dired+/dired+
/home/cray/.emacs.d/el-get/emacschrome/servers/el-get hides /home/cray/.emacs.d/el-get/el-get/el-get
/home/cray/.emacs.d/el-get/cmake-mode/cmake-mode hides /usr/share/emacs/site-lisp/cmake-mode
/home/cray/.emacs.d/el-get/remember/remember hides /usr/share/emacs/24.0.95/lisp/textmodes/remember
/home/cray/.emacs.d/el-get/magit/.dir-locals hides /usr/share/emacs/24.0.95/lisp/gnus/.dir-locals

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mail-utils server ampc-autoloads
re-builder .loaddefs arduino-mode cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs vkill sudo-save
smarttabs remember-autoloads qmake-mode pkgbuild-mode sh-script
executable pastebin muse-journal muse-book cus-edit cus-start cus-load
muse-project muse-latex muse-html muse-xml-common muse-protocols
muse-regexps derived muse muse-nested-tags muse-publish muse-autoloads
list-processes+ linum-off linum linum-ex icomplete+ icomplete go-mode
flyguess flyspell ispell evil-core undo-tree rect evil-vars dired-view
dired-sync dired-single dired-details dired-x ediff-merg ediff-diff
ediff-wind ediff-mult ediff-help ediff-init ediff-util dired-aux cssh
tramp tramp-compat auth-source eieio assoc gnus-util time-date mm-util
mail-prsvr password-cache shell pcomplete format-spec tramp-loaddefs
term disp-table ehelp electric ibuffer command-frequency
color-theme-twilight color-theme wid-edit cmake-mode thingatpt
byte-code-cache buffer-move windmove browse-kill-ring
auto-complete-config auto-complete edmacro kmacro preview-latex tex-site
auto-loads info anything byte-opt warnings advice advice-preload
any-ini-mode imenu ahg grep compile comint ansi-color ewoc log-edit ring
pcvs-util add-log diff-mode easy-mmode popup el-get help-mode easymenu
view autoload help-fns bytecomp byte-compile cconv macroexp cl package
tabulated-list dired regexp-opt tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image fringe
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Michael Albinus]

Cray Elliott <mp2e@archlinux.us> writes:

> For example, if you went to eshell and typed 'sudo rm -rf /opt/folder'
> it would complain about permissions being needed and wouldn't query
> for password. Bug doesn't exist with relative paths. Bug does exist with wildcards.

If you want to use absolute paths in eshell, you should apply

rm -rf /sudo::/opt/folder

Best regards, Michael.

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Stefan Monnier]

>> For example, if you went to eshell and typed 'sudo rm -rf
>> /opt/folder' it would complain about permissions being needed and
>> wouldn't query for password. Bug doesn't exist with relative paths.
>> Bug does exist with wildcards.
> If you want to use absolute paths in eshell, you should apply
> rm -rf /sudo::/opt/folder

While using Tramp might make sense, I think that "sudo rm -rf /foo/bar"
is a perfectly valid command and wonder why it wouldn't work correctly.


        Stefan

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> For example, if you went to eshell and typed 'sudo rm -rf
>>> /opt/folder' it would complain about permissions being needed and
>>> wouldn't query for password. Bug doesn't exist with relative paths.
>>> Bug does exist with wildcards.
>> If you want to use absolute paths in eshell, you should apply
>> rm -rf /sudo::/opt/folder
>
> While using Tramp might make sense, I think that "sudo rm -rf /foo/bar"
> is a perfectly valid command and wonder why it wouldn't work correctly.

In eshell, `sudo' is an built-in for `eshell/sudo':

~ $ which sudo
eshell/sudo is a compiled Lisp function in `em-unix.el'

In order to call the native sudo, one must apply

*sudo rm -rf /opt/folder

See also (info "(eshell)Built-ins")

>         Stefan

Best regards, Michael.

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Stefan Monnier]

>> While using Tramp might make sense, I think that "sudo rm -rf /foo/bar"
>> is a perfectly valid command and wonder why it wouldn't work correctly.
> In eshell, `sudo' is an built-in for `eshell/sudo':

That does not in itself explain why it doesn't do the right thing: the
intention seems fairly clear.


        Stefan

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> While using Tramp might make sense, I think that "sudo rm -rf /foo/bar"
>>> is a perfectly valid command and wonder why it wouldn't work correctly.
>> In eshell, `sudo' is an built-in for `eshell/sudo':
>
> That does not in itself explain why it doesn't do the right thing: the
> intention seems fairly clear.

Sure.

The problem is `rm', which is another built-in. Built-ins are not aware
of being called in a `su(do)?' context.

Sounds like a new feature in eshell. Do we want it? Do we know, that
there are no unwanted side effects, if (local) "/foo/bar" is handled as
(remote) "/su(do)?::/foo/bar" for *all* built-ins, when being called
from `eshell/su(do)?'?

>         Stefan

Best regards, Michael.

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Stefan Monnier]

>>>> While using Tramp might make sense, I think that "sudo rm -rf /foo/bar"
>>>> is a perfectly valid command and wonder why it wouldn't work correctly.
>>> In eshell, `sudo' is an built-in for `eshell/sudo':
>> That does not in itself explain why it doesn't do the right thing: the
>> intention seems fairly clear.
> Sure.
> The problem is `rm', which is another built-in.  Built-ins are not aware
> of being called in a `su(do)?' context.

Sounds like a bug in eshell/sudo: it should not use builtins.


        Stefan

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Sounds like a bug in eshell/sudo: it should not use builtins.

Don't know. Sometimes, it makes sense for builtins running under sudo.
Like `.', an alias for `eshell/.'. It sources a file, and executes
eshell commands from this file.

sudo . .eshell/history

sounds like a useful command. Just as example, other examples could  be there.

I still believe, we shall emphasize in the manual, that file names are
interpreted like in `find-file'. This is the spirit of `eshell'.
Otherwise, one shall use plain `shell'.

>         Stefan

Best regards, Michael.

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Stefan Monnier]

>> Sounds like a bug in eshell/sudo: it should not use builtins.
> Don't know. Sometimes, it makes sense for builtins running under sudo.
> Like `.', an alias for `eshell/.'. It sources a file, and executes
> eshell commands from this file.
> sudo . .eshell/history

"sudo . .eshell/history" means "execute the commands in .eshell/history
as user `root'".  I.e. it's very different from
". /sudo::.eshell/history" which runs those command as the current user.
I don't think eshell/sudo knows how to do it right.


        Stefan

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Michael Albinus]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> "sudo . .eshell/history" means "execute the commands in .eshell/history
> as user `root'".  I.e. it's very different from
> ". /sudo::.eshell/history" which runs those command as the current user.

I haven't said there's only one way to do it :-) I mean we should think
about, before we disable builtins in sudo. I'm still not convinced it is
a bug. In eshell, one must understand how file names are handled.

And, btw, people who don't like the current behaviour are free to add

alias sudo *sudo $*

to ~/.eshell/alias.

>         Stefan

Best regards, Michael.

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Stefan Monnier]

>> "sudo . .eshell/history" means "execute the commands in .eshell/history
>> as user `root'".  I.e. it's very different from
>> ". /sudo::.eshell/history" which runs those command as the current user.
> I haven't said there's only one way to do it :-) I mean we should
> think about, before we disable builtins in sudo.  I'm still not
> convinced it is a bug.
> In eshell, one must understand how file names are handled.

I'd be happy to hear of arguments in favor of the current behavior of
eshell/sudo w.r.t builtins.


        Stefan

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Thierry Volpiatto]

Hi Michael,

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

> And, btw, people who don't like the current behaviour are free to add
>
> alias sudo *sudo $*
Most people use such an alias because eshell/sudo is not working with
commands where files are not involved 
e.g "eshell/sudo uname -a" or "eshell/sudo fdisk -l" etc...

==> ssh: connect to host localhost port 22: Connection refused

Using default-directory instead of
/sudo:user@localhost:<default-directory> (which use ssh port 22!!!!)
fix it

--8<---------------cut here---------------start------------->8---
(let ((default-directory (if (string= host "localhost")
                             default-directory
                             (format "/sudo:%s@%s:%s" user host dir))))
--8<---------------cut here---------------end--------------->8---

But maybe I missed something?

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Thierry Volpiatto]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>> "sudo . .eshell/history" means "execute the commands in .eshell/history
>>> as user `root'".  I.e. it's very different from
>>> ". /sudo::.eshell/history" which runs those command as the current user.
>> I haven't said there's only one way to do it :-) I mean we should
>> think about, before we disable builtins in sudo.  I'm still not
>> convinced it is a bug.
>> In eshell, one must understand how file names are handled.
>
> I'd be happy to hear of arguments in favor of the current behavior of
> eshell/sudo w.r.t builtins.
It seem it doesn't ask for passwd at everytime 
(seem it read his timestamp in /var/lib/sudo/<user>/?).

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Thierry Volpiatto]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Hi Michael,
>
> Michael Albinus <michael.albinus@gmx.de> writes:
>
>> And, btw, people who don't like the current behaviour are free to add
>>
>> alias sudo *sudo $*
> Most people use such an alias because eshell/sudo is not working with
> commands where files are not involved 
> e.g "eshell/sudo uname -a" or "eshell/sudo fdisk -l" etc...
>
> ==> ssh: connect to host localhost port 22: Connection refused
>
> Using default-directory instead of
> /sudo:user@localhost:<default-directory> (which use ssh port 22!!!!)
> fix it
>
> (let ((default-directory (if (string= host "localhost")
>                              default-directory
>                              (format "/sudo:%s@%s:%s" user host dir))))
>
> But maybe I missed something?
And also it is using /bin/sh which is not aware of many system
maintenance commands mostly used as root with sudo.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Thierry Volpiatto]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>
>>>> "sudo . .eshell/history" means "execute the commands in .eshell/history
>>>> as user `root'".  I.e. it's very different from
>>>> ". /sudo::.eshell/history" which runs those command as the current user.
>>> I haven't said there's only one way to do it :-) I mean we should
>>> think about, before we disable builtins in sudo.  I'm still not
>>> convinced it is a bug.
>>> In eshell, one must understand how file names are handled.
>>
>> I'd be happy to hear of arguments in favor of the current behavior of
>> eshell/sudo w.r.t builtins.
> It seem it doesn't ask for passwd at everytime 
> (seem it read his timestamp in /var/lib/sudo/<user>/?).
No, it just doesn't use sudo at all! it is why no password is required.
And command which need a passwd e.g cat /etc/passwd- end up with
permission denied.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Stefan Monnier]

>> I'd be happy to hear of arguments in favor of the current behavior of
>> eshell/sudo w.r.t builtins.
> It seem it doesn't ask for passwd at everytime
> (seem it read his timestamp in /var/lib/sudo/<user>/?).

That rather sounds like a problem of the alternative code that
needs fixing.


        Stefan

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Michael Albinus]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

[Sorry for the delay, I was busy in RL last days]

> I'd be happy to hear of arguments in favor of the current behavior of
> eshell/sudo w.r.t builtins.

I've checked the implementation of eshell/sudo: It simply let-binds
default-directory to "/sudo:user@host:dir", and let the command like rm
run. That's why the built-in version of rm is in place.

Another implementation of sudo would not be in the spirit of eshell, I
think.

>         Stefan

Best regards, Michael.

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Michael Albinus]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

>> Hi Michael,

Hi Thierry,

>> Michael Albinus <michael.albinus@gmx.de> writes:
>>
>>> And, btw, people who don't like the current behaviour are free to add
>>>
>>> alias sudo *sudo $*
>> Most people use such an alias because eshell/sudo is not working with
>> commands where files are not involved 
>> e.g "eshell/sudo uname -a" or "eshell/sudo fdisk -l" etc...
>>
>> ==> ssh: connect to host localhost port 22: Connection refused
>>
>> Using default-directory instead of
>> /sudo:user@localhost:<default-directory> (which use ssh port 22!!!!)
>> fix it
>>
>> (let ((default-directory (if (string= host "localhost")
>>                              default-directory
>>                              (format "/sudo:%s@%s:%s" user host dir))))
>>
>> But maybe I missed something?
> And also it is using /bin/sh which is not aware of many system
> maintenance commands mostly used as root with sudo.

Does there exist a corresponding bug report? I'm short in time, but
maybe I could have a look on it later.

Best regards, Michael.

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Thierry Volpiatto]

Hi Michael,

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

> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>>> Hi Michael,
>
> Hi Thierry,
>
>>> Michael Albinus <michael.albinus@gmx.de> writes:
>>>
>>>> And, btw, people who don't like the current behaviour are free to add
>>>>
>>>> alias sudo *sudo $*
>>> Most people use such an alias because eshell/sudo is not working with
>>> commands where files are not involved 
>>> e.g "eshell/sudo uname -a" or "eshell/sudo fdisk -l" etc...
>>>
>>> ==> ssh: connect to host localhost port 22: Connection refused
This happen with a bad configuration of `tramp-default-proxies-alist':

--8<---------------cut here---------------start------------->8---
(add-to-list 'tramp-default-proxies-alist
             '(nil "\\`root\\'" "/ssh:%h:"))
--8<---------------cut here---------------end--------------->8---

With this with host set to nil,
(directory-file-p "/sudo:localhost:")
C-x C-f "/sudo:localhost:"
eshell/sudo
fail with error above.
The host should be set to the real name of the host we want to connect
on as root:

--8<---------------cut here---------------start------------->8---
(add-to-list 'tramp-default-proxies-alist
             '("\\`realhostname\\'" "\\`root\\'" "/ssh:%h:"))
--8<---------------cut here---------------end--------------->8---

>> And also it is using /bin/sh which is not aware of many system
>> maintenance commands mostly used as root with sudo.
>
> Does there exist a corresponding bug report? I'm short in time, but
> maybe I could have a look on it later.
No but you can reproduce easily with:

$ eshell/sudo fdisk -l
=>/bin/sh: fdisk: not found

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Stefan Monnier]

>> I'd be happy to hear of arguments in favor of the current behavior of
>> eshell/sudo w.r.t builtins.
> I've checked the implementation of eshell/sudo: It simply let-binds
> default-directory to "/sudo:user@host:dir", and let the command like rm
> run. That's why the built-in version of rm is in place.
> Another implementation of sudo would not be in the spirit of eshell, I
> think.

Spirit or not, the resulting behavior for `sudo' makes no sense and
should be fixed,


        Stefan

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I'd be happy to hear of arguments in favor of the current behavior of
>>> eshell/sudo w.r.t builtins.
>> I've checked the implementation of eshell/sudo: It simply let-binds
>> default-directory to "/sudo:user@host:dir", and let the command like rm
>> run. That's why the built-in version of rm is in place.
>> Another implementation of sudo would not be in the spirit of eshell, I
>> think.
>
> Spirit or not, the resulting behavior for `sudo' makes no sense and
> should be fixed,

Last attempt to convince you: The eshell manual gives as example

          ~ $ cd /ssh:otherhost:/etc
          /ssh:user@otherhost:/etc $ sudo find-file shadow

If you disable built-in commands inside sudo, you would disable all
other Lisp functions as well. Do we want this?

>         Stefan

Best regards, Michael.

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Stefan Monnier]

>> Spirit or not, the resulting behavior for `sudo' makes no sense and
>> should be fixed,
> Last attempt to convince you: The eshell manual gives as example
>           ~ $ cd /ssh:otherhost:/etc
>           /ssh:user@otherhost:/etc $ sudo find-file shadow
> If you disable built-in commands inside sudo, you would disable all
> other Lisp functions as well.  Do we want this?

The problem is the following:
- eshell/sudo has the same name as /usr/bin/sudo but does something
  slightly different.
- eshell/rm has the same name as /bin/rm but does something
  slightly different.
- the combination of the two leads to "sudo rm" doing something less
  slightly different.
I don't use Eshell myself, so I'm not sure what the best way to
fix this.  Maybe it's eshell/rm that needs fixing, maybe Eshell should
change to use different name for its `sudo', or maybe the solution
should be yet different.


        Stefan

bug#11194: 24.0.95; sudo rm doesn't work with absolute directory paths on the file system

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> The problem is the following:
> - eshell/sudo has the same name as /usr/bin/sudo but does something
>   slightly different.
> - eshell/rm has the same name as /bin/rm but does something
>   slightly different.

That's the idea of eshell's built-ins.

> - the combination of the two leads to "sudo rm" doing something less
>   slightly different.

Again, it does what you could expect from *eshell*. If you do not want
this behaviour, you could use *shell*. Or you could mask the built-in by
prepending a "*" to the command, as described.

> I don't use Eshell myself, so I'm not sure what the best way to
> fix this.  Maybe it's eshell/rm that needs fixing, maybe Eshell should
> change to use different name for its `sudo', or maybe the solution
> should be yet different.

The question is whether a command being an argument of "sudo" shall
still behave like other eshell commands. This is not only true for "rm"
(being `eshell/rm'), but for all commands which could be a valid Lisp
command.

>         Stefan

Best regards, Michael.