Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1380890 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#1380890 — 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

[toc] | [next] | [standalone]

#1380893

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

[toc] | [prev] | [next] | [standalone]

#1381402

On Sun, Apr 17, 2016 at 06:57:36PM -0700, Josh Triplett wrote:
> 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.

I had a look at O_NOUMASK and there are a few problems:

It's relatively easy to implement for open(2).  A few filesystems
implement their own open so I had to go into those filesystems and
modify how they handle current_umask too.  And FUSE support is tricky
so I passed on that.

The real problem is that mkdir/mkdirat/mknod/mknodat are affected by
umask, but there is no convenient flags parameter to pass the
O_NOUMASK flag.  So I think the patch only half-solves the problem.

I have a patch which needs a bit more testing, which I can post if you
think that's helpful, but I don't think it would be acceptable in its
current state.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

[toc] | [prev] | [next] | [standalone]

#1381452

On April 18, 2016 2:14:12 AM PDT, "Richard W.M. Jones" <rjones@redhat.com> wrote:
>On Sun, Apr 17, 2016 at 06:57:36PM -0700, Josh Triplett wrote:
>> 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.
>
>I had a look at O_NOUMASK and there are a few problems:
>
>It's relatively easy to implement for open(2).  A few filesystems
>implement their own open so I had to go into those filesystems and
>modify how they handle current_umask too.  And FUSE support is tricky
>so I passed on that.
>
>The real problem is that mkdir/mkdirat/mknod/mknodat are affected by
>umask, but there is no convenient flags parameter to pass the
>O_NOUMASK flag.  So I think the patch only half-solves the problem.
>
>I have a patch which needs a bit more testing, which I can post if you
>think that's helpful, but I don't think it would be acceptable in its
>current state.
>
>Rich.

Ironically this illustrates one of the limitations with flags arguments: this really belongs in the S_-flags, but we can't assume userspace is clean there... anymore than we can repurpose umask(-1).
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web