1

I've been following a thread on OSS-Security called Security risk of vim swap files. It looks like Vim and Emacs caught a CVE because the editors created temp files in the wrong place with too many file permissions.

I know Posix has a umask function to set the mask, but I don't really see a function to query it. I'm also aware some shells support UMASK, but I did not see it mentioned in the IEEE pages I visited. (Maybe I missed it; also see How to check umask for all users under Linux?).

How can programs query the umask value in a portable way?

1 Answer 1

4

The umask shell builtin with no argument prints the value of the current umask.

The umask() system call returns the value of the previous umask, so you can do:

umask = umask(0777);
umask(umask);

(or umask(umask = umask(0777)) as a common idiom).

That's what the umask shell builtin does. Note that in multi-threaded programs, that two stage process can be problematic if another thread calls umask() at the same time. But generally, programs usually do this on startup to find out the umask() they had initially.

To get the umask of another process, on recent versions of Linux (4.7 or above), you can do:

sed -ne 's/^Umask:[[:blank:]]*//p' < "/proc/$pid/status"

Note that the security consideration mentioned at the link you posted is not about permissions¹, but about the swp file containing the edited file's content but with a different extension (.swp instead of .php). And if the web server is not configured to not serve hidden files, then the .swp file will be served. And because it is not a php file, the raw content (the php source code as opposed to the result of it interpretation) will be served, potentially leaking sensitive information like database passwords.

That's why web servers are usually configured not to serve hidden files or files that end in ~ or follow common editor backup or temporary file name patterns.

Even if vim honoured the umask and you had a very restrictive umask like 077, it would still not help in the common case (think of cloud-hosted web server deployments) where there is only one user involved and the .swp file is created with the same owner as the file being edited.

A better solution is to tell vim to create the swp file in a directory only you have access to with the directory vim option. See

:h swap-file

within vim for details.

Or better still, don't edit the files directly in the area served by the web server, but on a separate copy, like a git or other working copy where you can muck about, track changes and push the new version to the actual web server once you're satisfied with it.


¹ Strictly speaking, there is a potential problem with permissions as well. vim will use the same permissions as the edited file for the .swp file (umask is not involved here) but will not replicate the ACLs if any. Having a user ACL on a file, means the permission field as returned by stat() will be seen as having extra permission for the group (because of the ACL mask), and the .swp file in those cases may have too wide permissions for the group.

5
  • Thanks. How would a C program, like Vim or Emacs, do it? It seems to me if they call m=umask(0) for the return value and then call umask(m) again to reset the mask they setup a race.
    – user56041
    Commented Nov 1, 2017 at 10:36
  • @jww, what race? The process umask can only be changed by the process itself. Commented Nov 1, 2017 at 10:37
  • Thanks again. It did not occur to me it was a per-process mask, and not a per-user-mask (even though the Posix page used the word "process" twice). Yeah, it looks like the Linux task_struct has a field for umask in its fs_struct. Also see Processes in the kernel docs.
    – user56041
    Commented Nov 1, 2017 at 11:55
  • "And if the web server is not configured to not serve hidden files..." - I was less concerned about this. My web server's owners are root:apache or root:www, so its enough for me to ensure the file permissions are correct. Apache won't be able to read and serve a 0600 file.
    – user56041
    Commented Nov 1, 2017 at 11:59
  • Are you the same fellow associated with Shell Shock? If so, good find.
    – user56041
    Commented Nov 1, 2017 at 12:29

You must log in to answer this question.