GNU bug report logs - #58781
28.2; move-file-to-trash may move file across filesystems

Previous Next

Package: emacs;

Reported by: Gustavo Barros <gusbrs.2016 <at> gmail.com>

Date: Tue, 25 Oct 2022 20:01:02 UTC

Severity: normal

Tags: security

Found in version 28.2

Full log


View this message in rfc822 format

From: Gustavo Barros <gusbrs.2016 <at> gmail.com>
To: 58781 <at> debbugs.gnu.org
Subject: bug#58781: 28.2; move-file-to-trash may move file across filesystems
Date: Tue, 25 Oct 2022 17:00:37 -0300
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.




This bug report was last modified 2 years and 234 days ago.

Previous Next


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