bug#58781: 28.2; move-file-to-trash may move file across filesystems

[Gustavo Barros]

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.