From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.bugs Subject: bug#60460: 30.0.50; [FR] avoid putting remote files to local trash Date: Mon, 2 Jan 2023 23:37:45 +0300 Message-ID: References: <87358tfglk.fsf@gmx.de> <87mt71dxhf.fsf@gmx.de> <87ilhoeqlf.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38897"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.2.9+54 (af2080d) (2022-11-21) Cc: ruijie@netyu.xyz, 60460@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 03 05:59:41 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 1pCZOn-0009pB-2g for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 03 Jan 2023 05:59:41 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pCZOF-0001Td-Kq; Mon, 02 Jan 2023 23:59:07 -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 1pCZOB-0001Qr-N7 for bug-gnu-emacs@gnu.org; Mon, 02 Jan 2023 23:59:04 -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 1pCZOA-0005r4-FZ for bug-gnu-emacs@gnu.org; Mon, 02 Jan 2023 23:59:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pCZO9-0001aK-T7 for bug-gnu-emacs@gnu.org; Mon, 02 Jan 2023 23:59:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jean Louis Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Jan 2023 04:59: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.16727219176049 (code B ref 60460); Tue, 03 Jan 2023 04:59:01 +0000 Original-Received: (at 60460) by debbugs.gnu.org; 3 Jan 2023 04:58:37 +0000 Original-Received: from localhost ([127.0.0.1]:44475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pCZNl-0001ZV-3Z for submit@debbugs.gnu.org; Mon, 02 Jan 2023 23:58:37 -0500 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:49371) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pCZNf-0001ZG-96 for 60460@debbugs.gnu.org; Mon, 02 Jan 2023 23:58:35 -0500 Original-Received: from localhost ([::ffff:197.239.13.208]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000055D77.0000000063B3B5F9.0000508A; Mon, 02 Jan 2023 21:58:32 -0700 Content-Disposition: inline In-Reply-To: <87ilhoeqlf.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:252375 Archived-At: * Michael Albinus [2023-01-02 21:31]: > But there are other attack vectors then. Trash files from root user, > located in the user's home directory, could have weak permissions. Those are decisions of administrator and user. Permissions they put on files is their decision and freedom. Any file owned by root and moved to user's home directory somewhere in the Trash, will have how I tested it, same permission as in root accessible directories. Let us say /etc or /usr and so on, those files are anyway either visible by users or some of them in /etc protected by permissions. Those are system decisions. Who has sudo rights is system administrator, not necessarily main, but then those people made decisions. And moving into trash is useful, especially in case of files in /etc Let administrators decide what they want. Emacs is high level interface, not low level. On high level there is almost nothing to be decided what people decided on low level. For me is not logical to try to prevent people what they want. Give them option, but don't try preventing them on that high level to do this or that, what they otherwise can do in their system by using different file manager. 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. > > Settings in Emacs to delete by moving trash are explicit decisions of > > user. Same with `sudo'. Administrator gives privilege to `sudoer', > > and that sudoer may do what he thinks is right and good. > > > > I would personally prefer that sudo editing goes in trash. > > You are free to configure respective connection-local variables. 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. > > Anyway, when editing with sudo I see this file: > > > > lrwxrwxrwx 1 root root 46 Jan 2 19:27 .#at.deny -> admin@protected.1904257840789327597 > > > > which is dangling symlink, do you know about it? Is it bug? > > No, it is a lock file. See (info "(elisp) File Locks") Alright. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/