From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gustavo Barros Newsgroups: gmane.emacs.bugs Subject: bug#58781: 28.2; move-file-to-trash may move file across filesystems Date: Tue, 25 Oct 2022 18:57:46 -0300 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28015"; mail-complaints-to="usenet@ciao.gmane.io" To: 58781@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 25 23:59:49 2022 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 1onRxc-00073g-Sq for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 25 Oct 2022 23:59:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1onRwu-0000CC-Lm; Tue, 25 Oct 2022 17:59:04 -0400 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 1onRws-0008Uv-Lg for bug-gnu-emacs@gnu.org; Tue, 25 Oct 2022 17:59:02 -0400 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 1onRws-0003jw-5x for bug-gnu-emacs@gnu.org; Tue, 25 Oct 2022 17:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1onRwr-0007tm-Ml for bug-gnu-emacs@gnu.org; Tue, 25 Oct 2022 17:59:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gustavo Barros Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Oct 2022 21:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58781 X-GNU-PR-Package: emacs Original-Received: via spool by 58781-submit@debbugs.gnu.org id=B58781.166673508730295 (code B ref 58781); Tue, 25 Oct 2022 21:59:01 +0000 Original-Received: (at 58781) by debbugs.gnu.org; 25 Oct 2022 21:58:07 +0000 Original-Received: from localhost ([127.0.0.1]:52539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1onRvz-0007sZ-0j for submit@debbugs.gnu.org; Tue, 25 Oct 2022 17:58:07 -0400 Original-Received: from mail-pg1-f169.google.com ([209.85.215.169]:38905) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1onRvw-0007s3-FX for 58781@debbugs.gnu.org; Tue, 25 Oct 2022 17:58:05 -0400 Original-Received: by mail-pg1-f169.google.com with SMTP id 20so12894363pgc.5 for <58781@debbugs.gnu.org>; Tue, 25 Oct 2022 14:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=uHEgkH9D7aQpDO1uQoh3nn1hXJT7XX2ftK+1Xs9RYbg=; b=G8E2PvfRr8E5mmm2/SS6c0yj9nK1oPeQRLa0YwKLsAvCzWlz3Fbb8GNyEDIud0Wum7 f++xx98vgxPZf1XTISMQVgrOHIYspcJO/Z0d43OkdQs6taNyaL/oiE1f14DXDDXmN2by 2PikJVDNuhhXx/1B2Eij9ov8giBpTahaXzBoNiSK02gN4qmdjfWRoBjQwFR3d+ksjjFY PArsgAC+HJ47Gs/msG/gzlvAC1lL4ostKn87tGLD2UJ3Yncr36iu8OnYFHjvDhOVam5Y /wmgMqclDq3LNVTDx2Rn6/OPacY8vMIJc50/oyRo5rlbMyjygYGv5+hxMNM037f5Wn6S s/DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uHEgkH9D7aQpDO1uQoh3nn1hXJT7XX2ftK+1Xs9RYbg=; b=LFUfYZXW1VYCD941L1do4LDGs7GyUIrbl0/WIayFfkORppnXfXPgaC/2fxRE6vtWc2 L948nhUNN8eL6J4QJMGdepLyPPjDcSF2B45JQlwfW/HsZJS3s7pNTOYUWpG4a4miIRR+ +EiCWj7OI1Dyxyi2EvAtNfLnS42p2oD+Uc4L8JQwgn2ev37rPvqaXQw9zEslEr5bcgFH FeaQW9t/c6yu4yiyzmRo3hYvjZ1CBYH3G64A+dMjkuq1tv6KBkhhIh57wjI/k5EKLz1w wc9i6+cq7EgYt8t5k1MT9BdbymwL0oilT+AY7IdiHp+OnmfI8f4bSF+qFuNVg0nl4R99 fQTQ== X-Gm-Message-State: ACrzQf2E0cNGjG6rnvPX5hS/Uciq4FdlcwzO9o9GlAOVLUooZoA61mbm 68taJx/3PAflQqTdk/VUR6x5GbM/s8bnazXjLhxZPmEV4R4= X-Google-Smtp-Source: AMsMyM7jkZ+ByDJIoqZ90TXbVMvyl/Pmwz6k+RK6SCLNGhxqlYnZzrJ19Skxpw51lya/q09e5pPy7Wh5Z3cBwLIuUSU= X-Received: by 2002:a63:84c2:0:b0:46e:f239:354c with SMTP id k185-20020a6384c2000000b0046ef239354cmr14316332pgd.147.1666735078105; Tue, 25 Oct 2022 14:57:58 -0700 (PDT) In-Reply-To: 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: , Original-Sender: "bug-gnu-emacs" Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:246176 Archived-At: Hi All, a couple of additions to this report. First, I did some searching on the freedesktop.org specs, which I found at: https://specifications.freedesktop.org/trash-spec/trashspec-lates= t.html. The relevant bit seems to be: "A system can have one or more trash directories. The contents of any trash directory are to be compliant with the same standard, described below. For every user a =E2=80=9Chome trash=E2=80=9D directory MUST be available. = Its name and location are $XDG_DATA_HOME/Trash; $XDG_DATA_HOME is the base directory for user-specific data, as defined in the Desktop Base Directory Specification . The =E2=80=9Chome trash=E2=80=9D SHOULD function as the user's main trash d= irectory. Files that the user trashes from the same file system (device/partition) SHOULD be stored here (see the next section for the storage details). A =E2=80=9Chome trash=E2=80=9D directory SHOULD be automa= tically created for any new user. If this directory is needed for a trashing operation but does not exist, the implementation SHOULD automatically create it, without any warnings or delays. The implementation MAY also support trashing files from the rest of the system (including other partitions, shared network resources, and removable devices) into the =E2=80=9Chome trash=E2=80=9D directory . This i= s a =E2=80=9Cfailsafe=E2=80=9D method: trashing works for all file locations, t= he user can not fill up any space except the home directory, and as other users generally do not have access to it, no security issues arise. However, this solution leads to costly file copying (between partitions, over the network, from a removable device, etc.) A delay instead of a quick =E2=80=9Cdelete=E2=80=9D operation can be unpleasant to = users. An implementation MAY choose not to support trashing in some of these cases (notably on network resources and removable devices). This is what some well known operating systems do. It MAY also choose to provide trashing in the =E2=80=9Ctop directories=E2= =80=9D of some or all mounted resources." Etc. This means `move-file-to-trash' is technically within specs, since "The implementation MAY also support trashing files from the rest of the system (including other partitions, shared network resources, and removable devices) into the =E2=80=9Chome trash=E2=80=9D directory." I hear= tily disagree though with the "no security issues arise" statement. And I still think it would be better to support trashing to "top directories". Of course, this makes this report a "feature request" rather than a "bug". Second, for anyone else half as concerned with this as I am, you may be interested in a workaround too. For the time being, I'm using: (defun system-move-file-to-trash (filename) (if-let ((exec (executable-find "gio"))) (let ((fn (directory-file-name (expand-file-name filename)))) (set-process-sentinel (start-process "trash-file" nil exec "trash" fn) (lambda (_proc event) (when (string-match-p "^exited abnormally.*" event) (message "Sorry, couldn't trash the file."))))) (error "Executable `gio' not found, can't trash file."))) This is somewhat ad hoc, using the way `move-file-to-trash' is constructed to support Windows I suppose, but it gets things done. It is system dependent too, but it is a matter of finding the right command line incantation for trashing a file in your system to adjust things. Best regards, Gustavo. On Tue, 25 Oct 2022 at 17:00, Gustavo Barros wrote: > > Hi All, > > I'm trying to investigate bug#58721 > (https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-10/msg01987.html), > couldn't figure it out yet, but in the process of doing so, I've found > another issue. Namely, that `move-file-to-trash' may move the file > across filesystems with some undesired implications, including > potential security risk. > > This happens because, for the case using the freedesktop.org method, > in setting trash directory, the procedure is the following: > > (xdg-data-dir > (directory-file-name > (expand-file-name "Trash" > (or (getenv "XDG_DATA_HOME") > "~/.local/share")))) > > There's no provision to check whether `xdg-data-dir' belongs to the > same filesystem (partition) as the file being moved there. As a > result, the `move-file-to-trash' may move the file across filesystems. > Indeed, I've tested it and, if you are trashing a file from a > different partition, it ends in "~/.local/share" regardless. > > This is a problem for at least two reasons. First, what should be a > cheap operation, a simple "rename", can become very costly if what is > being trashed is large, because now the file has to be physically > moved. Second, it may be a security risk. > > It certainly is for my setup, for example. It involves two > partitions, one for the operating system, unencrypted, which includes > "/home/username/", and another one, luks encrypted, where I keep my > user files, and which is symlinked to "/home/username/". So, trashing > a file from dired, with such a setup, results in the files being > stored unencrypted, when they shouldn't. I wouldn't say there's > nothing much peculiar in this setup, it is certainly legitimate. > > I'm not sure what's the standard expected behavior (I suppose the > freedesktop.org specs for it). But my distro's file manager (which > happens to be `nemo' from Linux Mint) certainly does not do that. It > sends such files to a different trash directory at the root of the > other partition's mount point. > > Best regards, > Gustavo.