GNU bug report logs - #60460
30.0.50; [FR] avoid putting remote files to local trash

Previous Next

Full log

Message #57 received at 60460 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Ruijie Yu <ruijie <at> netyu.xyz>
Cc: Jean Louis <bugs <at> gnu.support>, 60460 <at> debbugs.gnu.org
Subject: Re: bug#60460: 30.0.50; [FR] avoid putting remote files to local trash
Date: Sat, 07 Jan 2023 13:48:16 +0100

Ruijie Yu <ruijie <at> netyu.xyz> writes:

> Hi Michael and Jean,

Hi,

> 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 <at> s1|sshx:u2 <at> s2:.ssh/known_hosts" ->
> "/sshx:u1 <at> s1|sshx:u2 <at> 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.

We've used this approach in Emacs 27 (Tramp 2.4), but it wasn't robust
enough. So this was removed from Tramp, knowing that users could define
their own `system-move-file-to-trash'.

>> `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).

So `remote-file-name-inhibit-delete-by-moving-to-trash' would fit your use case perfectly.

> Best,
>
>
> RY

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.