bug#57395: 28.1; tramp-allow-unsafe-temporary-files assumes root:root rw-r--r-- files are secret and assumes temporary-directory is public

[Manuel Giraud]

"Trent W. Buck" <trentbuck@gmail.com> writes:

[...]

> It looks like Emacs 28's tramp is concerned about an attack like this:
>
>    1. I open /ssh:example.com:/etc/shadow
>    2. I make a change but don't hit C-x C-s right away
>    3. auto-save creates a WORLD-READABLE backup in local /tmp
>    4. oops, now attackers on the local system can read the passwords
>    from /tmp/shadow.XXXXXX!

FWIW, I tested this on the upcoming Emacs 29 and it is not the case
anymore.  If the remote file is owned by root and mode 0600, the
corresponding auto-save file will be owned by the user and also mode
0600 (not world-readable).  I think it makes sense since said user was
granted access to this file.

[...]

> There are several problems here.
>
>    1. if you say "no" to the security prompt,
>       the file buffer is actually open.
>       It just remains in fundamental mode, and
>       is not made the current buffer.
>
>       You can select it without another warning with C-x C-f or C-x b.

This is still true in Emacs 29 and a problem as a "no" should not open
the file.

>    2. tramp wrongly assumes every root-owned file is secret.
>       This is silly for files like

[...]

>    3. tramp assumes non-root-owned files are NOT secret, i.e.
>       lulls users into a false sense of protection.

[...]

>    4. tramp wrongly assumes temporary-file-directory is public.
>       This is true for /tmp but not for $XDG_RUNTIME_DIR.

[...]

Those three points are also still true in Emacs 29.  I think we need a
more fine grained method to tell if a file is "dangerous" and if
'temporary-file-directory' is safe enough.

> I think the current large number of false-positives (#2, #4) and
> mean that this security check is currently harmful.
>
> Quacking/googling suggests everyone else who runs into this prompt, simply 
> turns it off.
> Rather than disabling it per-user, I'd rather we improve it.
> Or, decide it's too hard to improve, and remove it entirely (thereby
> reducing maintenance burden).

I think it is better to improve than to remove those checks.
-- 
Manuel Giraud