umask shell builtin with no argument prints the value of the current
umask() system call returns the value of the previous
umask, so you can do:
umask = umask(0777);
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.
vim honoured the
umask and you had a very restrictive
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
vim option. See
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.