Subject: Re: [PATCH v2 0/2] vfs: Define new syscall getumask.
To: Colin Walters <walters@verbum.org>,
        "Richard W.M. Jones" <rjones@redhat.com>, linux-kernel@vger.kernel.org
References: <1460552272-15985-1-git-send-email-rjones@redhat.com>
 <1460562105.353100.577697153.013DF466@webmail.messagingengine.com>
Cc: tglx@linutronix.de, mingo@redhat.com, akpm@linux-foundation.org,
        luto@kernel.org, viro@zeniv.linux.org.uk,
        mathieu.desnoyers@efficios.com, zab@redhat.com, emunson@akamai.com,
        paulmck@linux.vnet.ibm.com, aarcange@redhat.com, josh@joshtriplett.org,
        xemul@parallels.com, sfr@canb.auug.org.au, milosz@adfin.com,
        rostedt@goodmis.org, arnd@arndb.de, ebiederm@xmission.com,
        gorcunov@openvz.org, iulia.manda21@gmail.com,
        dave.hansen@linux.intel.com, mguzik@redhat.com, adobriyan@gmail.com,
        dave@stgolabs.net, linux-api@vger.kernel.org, gorcunov@gmail.com,
        fw@deneb.enyo.de
From: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <57143B74.3070302@zytor.com>
Date: Sun, 17 Apr 2016 18:42:12 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <1460562105.353100.577697153.013DF466@webmail.messagingengine.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1376
Lines: 33

On 04/13/16 08:41, Colin Walters wrote:
> On Wed, Apr 13, 2016, at 08:57 AM, Richard W.M. Jones wrote:
> 
>> 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...

	-hpa