Re: [PATCH v2 0/2] vfs: Define new syscall getumask.

On Sun, Apr 17, 2016 at 06:42:12PM -0700, H. Peter Anvin wrote:

On 04/13/16 08:41, Colin Walters wrote:

quoted

On Wed, Apr 13, 2016, at 08:57 AM, Richard W.M. Jones wrote:

quoted

It's not possible to read the process umask without also modifying it,
which is what umask(2) does.  A library cannot read umask safely,
especially if the main program might be multithreaded.

I assume you just want to do this from a shared library so you can
determine whether or not you need to call fchown() after making files
and the like?  If that's the case it'd be good to note it in the commit
message.

BTW...it might be a good idea to add a flags argument:
https://lwn.net/Articles/585415/

Did you consider calling this `umask2`, having the initial version only support
retrieving it via a UMASK_GET flag, and lay the groundwork to support
setting a threadsafe umask with a UMASK_SET_THREAD flag?

The comments on that article also list a number of problems with this
approach, related to how undefined flags are handled.

In fact, if it wasn't for this exact problem then umask(-1) would have
been the logical way to deal with this, but because umask(2) is defined
to have an internal & 07777 it becomes infeasible at least in theory.
In practice it might work...

However, see previous discussions about making this available in /proc.
 Also, I really think there is something to be said for a O_NOUMASK
option...

O_NOUMASK seems potentially useful to support implementation of umask
entirely in userspace, which also addresses thread-safety.  A program
could read its process umask out at startup, handle umask entirely in
userspace (including for threads), and only interact with the system
umask after fork and before exec.

- Josh Triplett