From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ruijie Yu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#60460: 30.0.50; [FR] avoid putting remote files to local trash Date: Fri, 06 Jan 2023 21:53:35 -0600 Message-ID: References: <87358tfglk.fsf@gmx.de> <87mt71dxhf.fsf@gmx.de> <87ilhoeqlf.fsf@gmx.de> <87bkngdmxd.fsf@gmx.de> Reply-To: Ruijie Yu Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29853"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.8.13; emacs 29.0.60 Cc: Jean Louis , 60460@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 07 05:38:21 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pE0yK-0007c6-H9 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 07 Jan 2023 05:38:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pE0y4-0006z2-K4; Fri, 06 Jan 2023 23:38:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pE0y2-0006yn-U4 for bug-gnu-emacs@gnu.org; Fri, 06 Jan 2023 23:38:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pE0y2-0000F2-EB for bug-gnu-emacs@gnu.org; Fri, 06 Jan 2023 23:38:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pE0y1-0007mU-Ro for bug-gnu-emacs@gnu.org; Fri, 06 Jan 2023 23:38:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ruijie Yu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Jan 2023 04:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60460 X-GNU-PR-Package: emacs Original-Received: via spool by 60460-submit@debbugs.gnu.org id=B60460.167306622429832 (code B ref 60460); Sat, 07 Jan 2023 04:38:01 +0000 Original-Received: (at 60460) by debbugs.gnu.org; 7 Jan 2023 04:37:04 +0000 Original-Received: from localhost ([127.0.0.1]:56282 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pE0x2-0007km-QH for submit@debbugs.gnu.org; Fri, 06 Jan 2023 23:37:04 -0500 Original-Received: from netyu.xyz ([152.44.41.246]:51430 helo=mail.netyu.xyz) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pE0wz-0007kc-LI for 60460@debbugs.gnu.org; Fri, 06 Jan 2023 23:36:58 -0500 Original-Received: from fw.net.yu.netyu.xyz (99-87-204-218.lightspeed.irvnca.sbcglobal.net [99.87.204.218]) by netyu.xyz (OpenSMTPD) with ESMTPSA id 3393dbb1 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 7 Jan 2023 04:36:56 +0000 (UTC) In-reply-to: <87bkngdmxd.fsf@gmx.de> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:252765 Archived-At: 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 writes: > Jean Louis 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