bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Ruijie Yu]

Hi Michael and Jean,

Sorry for the radio silence since my first few messages in this thread
-- life decided to become busy.  Anyways, here below (inline) are some
of my thoughts.

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

> Jean Louis <bugs@gnu.support> writes:
>
> Hi Jean,
>
>> [...]
>>
>> If I can run other file manager with sudo and move to Trash anywhere
>> it is specified, then let it be for Emacs users too, as by trying to
>> "secure" something what otherwise was decided on low level, makes no
>> sense.
>>
>> We can't say later "Emacs is more secure as file manager because it
>> does not allow you to move files managed with sudo to Trash" --
>> because it is not "more secure" as it is high level, not low level.
>
> All true, but there are individual decisions by users. I don't see why
> we shall add a special case for sudo (and su, doas, sudoedit, sg, ...) -
> all of them identify remote (possibly root owned) files and shall be
> handled as such. And then, there are also multi-hop remote file names,
> which would need another handling then for sudo and friends.

Considering the security implications of moving remote files into user
trash, does it make sense if we modify the `move-file-to-trash' function
such that when a remote file is to be trashed, it is trashed into the
trash location *of the same remote*?

That is, if we want to trash "/sudo::/etc/sudoers.d/foo" using the
modified `move-file-to-trash', we can move "/sudo::/etc/sudoers.d/foo"
into somewhere under "/sudo::.local/share/Trash/".  This way the file
never leaves the remote, and it does not matter what type the remote is.
In addition, trashing files from multi-hop remotes would be supported
natively with the same behavior:
"/sshx:u1@s1|sshx:u2@s2:.ssh/known_hosts" ->
"/sshx:u1@s1|sshx:u2@s2:.local/share/Trash/...".

We could lock this proposed change behind a flag to retain backward
compatibility for those who still prefer to trash remote files by moving
them into local trash directory.  Regardless, the behavior before and
after the change for local files should remain the same.

> `remote-file-name-inhibit-delete-by-moving-to-trash' is just an offer as
> convenience user option, nobody is obliged to use it. There are still
> connection-local variables or `system-move-file-to-trash' for users with
> the need of more fine-grained configuration.
>
>> Right now I use my function `system-move-file-to-trash' as recommended
>> by function `move-file-to-trash' and that is great option, I like that
>> configuration, so I can decide myself what get moved to Trash and what
>> not, so I will expand it to recognize sudo paths.
>
> Sigh.

For my original problem, what I did was to add a hook to `dired-mode' to
make the offending variable buffer-local, like the following.

(defun cfg-dired-setup ()
  "Custom setup hook for `dired-mode'."
  (interactive)
  ;; other configs omitted
  (cfg-dired-setup--avoid-remote-trash))

(defun cfg-dired-setup--avoid-remote-trash ()
  (when (and (boundp 'dired-directory)
             dired-directory
             (file-remote-p dired-directory))
    (setq-local delete-by-moving-to-trash nil)))

(add-hook 'dired-mode-hook #'cfg-dired-setup)

This only fixes my own issue for remote dired buffers, but would not fix
the trashing issue generally (for example within an eshell session or in
elisp programatically).

> Best regards, Michael.

Best,


RY