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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 17 Apr 2016 18:42:12 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Colin Walters <walters@...bum.org>,
	"Richard W.M. Jones" <rjones@...hat.com>,
	linux-kernel@...r.kernel.org
Cc:	tglx@...utronix.de, mingo@...hat.com, akpm@...ux-foundation.org,
	luto@...nel.org, viro@...iv.linux.org.uk,
	mathieu.desnoyers@...icios.com, zab@...hat.com, emunson@...mai.com,
	paulmck@...ux.vnet.ibm.com, aarcange@...hat.com,
	josh@...htriplett.org, xemul@...allels.com, sfr@...b.auug.org.au,
	milosz@...in.com, rostedt@...dmis.org, arnd@...db.de,
	ebiederm@...ssion.com, gorcunov@...nvz.org,
	iulia.manda21@...il.com, dave.hansen@...ux.intel.com,
	mguzik@...hat.com, adobriyan@...il.com, dave@...olabs.net,
	linux-api@...r.kernel.org, gorcunov@...il.com, fw@...eb.enyo.de
Subject: Re: [PATCH v2 0/2] vfs: Define new syscall getumask.

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