[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160418015736.GA16600@x>
Date: Sun, 17 Apr 2016 18:57:36 -0700
From: Josh Triplett <josh@...htriplett.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Colin Walters <walters@...bum.org>,
"Richard W.M. Jones" <rjones@...hat.com>,
linux-kernel@...r.kernel.org, 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, 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 Sun, Apr 17, 2016 at 06:42:12PM -0700, H. Peter Anvin wrote:
> 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...
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
Powered by blists - more mailing lists