GNU Emacs version 25.3.1 (and other versions most likely) ignores umask when creating a backup save file ("[ORIGINAL_FILENAME]~") resulting in files that may be world readable or otherwise accessible in ways not intended by the user running the emacs binary.
Created emacs tracking bugs for this issue:
Affects: fedora-all [bug 1508789]
It would be nice to have a reproducer in this bugzilla. Also, why is a vim discussion linked as a reference?
$ rpm -q emacs
$ umask 077
$ echo hello > foo
$ ls -l foo*
-rw------- 1 jsynacek jsynacek 6 Nov 7 14:12 foo
$ emacs -Q foo &
<edit foo and save it>
$ ls -l foo*
-rw------- 1 jsynacek jsynacek 11 Nov 7 14:12 foo
-rw------- 1 jsynacek jsynacek 6 Nov 7 14:12 foo~
For an example of what I think the bug report is about, see upstream report at
ls -l foo # -> -rw-rw-r--
emacs-25.3 -Q foo
make some changes and save
ls -l foo*
So, Emacs (intentionally) preserves the permissions of the original file when creating a backup (Emacs doesn't have "swap" files). Creating a CVE for this seems a bit of a stretch to me.
gedit, for example, seems to behave exactly the same way as Emacs, but doesn't create backups by default, whereas Emacs does. After a very brief and incomplete search, it seems like newer applications prefer to create backups in a central location (eg in HOME) rather than alongside the original file. This is available in Emacs by setting backup-directory-alist.
(In reply to Glenn Morris from comment #4)
> For an example of what I think the bug report is about, see upstream report
Thanks! I have also found https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=231bfd6818890c0c22181ad253f09c8f2399461d, which looked like it fixed this, but it didn't.
> So, Emacs (intentionally) preserves the permissions of the original file
> when creating a backup (Emacs doesn't have "swap" files). Creating a CVE for
> this seems a bit of a stretch to me.
I agree. Also, I like the ~/.emacs.d/backup solution, I used something similar as well. I'm not sure how editing remote files would work, though, but I guess that can be solved easily too.
To date, there's no change in upstream Emacs that "fixes" this. I don't think Emacs has even decided yet if this is something that needs fixing.
Red Hat Product Security has rated this issue as having Low security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.