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.