Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1380893
| From | Josh Triplett <josh@joshtriplett.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2 0/2] vfs: Define new syscall getumask. |
| Date | 2016-04-18 04:00 +0200 |
| Message-ID | <rp6DN-5xU-19@gated-at.bofh.it> (permalink) |
| References | <rnsyK-1lV-23@gated-at.bofh.it> <rnvdh-3q8-27@gated-at.bofh.it> <rp6u6-5tz-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH v2 0/2] vfs: Define new syscall getumask. "H. Peter Anvin" <hpa@zytor.com> - 2016-04-18 03:50 +0200
Re: [PATCH v2 0/2] vfs: Define new syscall getumask. Josh Triplett <josh@joshtriplett.org> - 2016-04-18 04:00 +0200
Re: [PATCH v2 0/2] vfs: Define new syscall getumask. "Richard W.M. Jones" <rjones@redhat.com> - 2016-04-18 11:20 +0200
Re: [PATCH v2 0/2] vfs: Define new syscall getumask. "H. Peter Anvin" <hpa@zytor.com> - 2016-04-18 12:10 +0200
csiph-web