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

Groups > linux.kernel > #1378184 > unrolled thread

[PATCH v4 0/3] vfs: Define new syscall umask2 [formerly getumask]

Back to article view | Back to linux.kernel

Contents

  [PATCH v4 0/3] vfs: Define new syscall umask2 [formerly getumask] "Richard W.M. Jones" <rjones@redhat.com> - 2016-04-13 21:10 +0200
    [PATCH v4 2/3] x86: Wire up new umask2 system call on x86. "Richard W.M. Jones" <rjones@redhat.com> - 2016-04-13 21:10 +0200
    umask2 man page (was: Re: [PATCH v4 0/3] vfs: Define new syscall  umask2 [formerly getumask]) "Richard W.M. Jones" <rjones@redhat.com> - 2016-04-13 21:40 +0200
    Re: [PATCH v4 0/3] vfs: Define new syscall umask2 [formerly getumask] "H. Peter Anvin" <hpa@zytor.com> - 2016-04-13 21:50 +0200
      Re: [PATCH v4 0/3] vfs: Define new syscall umask2 [formerly getumask] Florian Weimer <fw@deneb.enyo.de> - 2016-04-13 22:50 +0200
        Re: [PATCH v4 0/3] vfs: Define new syscall umask2 [formerly getumask] "Richard W.M. Jones" <rjones@redhat.com> - 2016-04-13 23:00 +0200
    Re: [PATCH v4 0/3] vfs: Define new syscall umask2 [formerly  getumask] Stephen Rothwell <sfr@canb.auug.org.au> - 2016-04-14 01:10 +0200
      Re: [PATCH v4 0/3] vfs: Define new syscall umask2 [formerly getumask] "Richard W.M. Jones" <rjones@redhat.com> - 2016-04-14 11:20 +0200

#1378184 — [PATCH v4 0/3] vfs: Define new syscall umask2 [formerly getumask]

v3 -> v4:

 - Rename the syscall: getumask becomes umask2.

 - Add flags parameter, with one flag (UMASK_GET_MASK).

 - Expand the rationale for this change in the first commit message.

 - Add a selftest.

 - Retest everything.

--------------------

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.

This patch series adds a new system call "umask2".  This adds a flags
parameter.  Specifying flags=UMASK_GET_MASK allows the umask of the
current process to be read without modifying it.

This leaves open the possibility in future of adding a per-thread
umask, set or read with other flags.  This is not implemented.

Another approach to this has been attempted before, adding something
to /proc, although it didn't go anywhere.  See:

  http://comments.gmane.org/gmane.linux.kernel/1292109

Another way to solve this would be to add a thread-safe getumask to
glibc.  Since glibc could own the mutex, this would permit libraries
linked to this glibc to read umask safely.  I should also note that
man-pages documents getumask(3), but no version of glibc has ever
implemented it.

Rich.

[toc] | [next] | [standalone]

#1378188 — [PATCH v4 2/3] x86: Wire up new umask2 system call on x86.

Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
---
 arch/x86/entry/syscalls/syscall_32.tbl | 1 +
 arch/x86/entry/syscalls/syscall_64.tbl | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl
index b30dd81..ccf75ba 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -386,3 +386,4 @@
 377	i386	copy_file_range		sys_copy_file_range
 378	i386	preadv2			sys_preadv2
 379	i386	pwritev2		sys_pwritev2
+380	i386	umask2			sys_umask2
diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl
index cac6d17..e566c64 100644
--- a/arch/x86/entry/syscalls/syscall_64.tbl
+++ b/arch/x86/entry/syscalls/syscall_64.tbl
@@ -335,6 +335,7 @@
 326	common	copy_file_range		sys_copy_file_range
 327	64	preadv2			sys_preadv2
 328	64	pwritev2		sys_pwritev2
+329	common	umask2			sys_umask2
 
 #
 # x32-specific system call numbers start at 512 to avoid cache impact
-- 
2.7.4

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

#1378206 — umask2 man page (was: Re: [PATCH v4 0/3] vfs: Define new syscall umask2 [formerly getumask])

UMASK(2)                   Linux Programmer's Manual                  UMASK(2)



NAME
       umask, umask2 - get and set file mode creation mask

SYNOPSIS
       #include <sys/types.h>
       #include <sys/stat.h>

       mode_t umask(mode_t mask);

       #define _GNU_SOURCE
       #include <fcntl.h>
       #include <sys/types.h>
       #include <sys/stat.h>

       mode_t umask2(mode_t mask, int flags);

DESCRIPTION
       umask()  sets  the calling process's file mode creation mask (umask) to
       mask & 0777 (i.e., only the file permission bits of mask are used), and
       returns the previous value of the mask.

       If flags is 0, then umask2() is the same as umask().

       If flags is UMASK_GET_MASK then umask2() ignores the mask parameter and
       returns the process's current umask.  The process's current mask is not
       modified in this case.

       The  umask  is  used  by open(2), mkdir(2), and other system calls that
       create files to modify the permissions placed on newly created files or
       directories.   Specifically,  permissions  in  the umask are turned off
       from the mode argument to open(2) and mkdir(2).

       Alternatively, if the parent directory has a default ACL (see  acl(5)),
       the umask is ignored, the default ACL is inherited, the permission bits
       are set based on the inherited ACL, and permission bits absent  in  the
       mode  argument  are turned off.  For example, the following default ACL
       is equivalent to a umask of 022:

           u::rwx,g::r-x,o::r-x

       Combining the effect of this default ACL with a mode argument  of  0666
       (rw-rw-rw-), the resulting file permissions would be 0644 (rw-r--r--).

       The  constants  that should be used to specify mask are described under
       stat(2).

       The typical default value for the process  umask  is  S_IWGRP | S_IWOTH
       (octal  022).   In the usual case where the mode argument to open(2) is
       specified as:

           S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH

       (octal 0666) when creating a new file, the permissions on the resulting
       file will be:

           S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH

       (because 0666 & ~022 = 0644; i.e., rw-r--r--).

RETURN VALUE
       The  umask()  system call always succeeds and the previous value of the
       mask is returned.

       The umask2() system call returns the process's current  umask  on  suc‐
       cess.  On error it returns -1 and sets errno appropriately.

CONFORMING TO
       SVr4, 4.3BSD, POSIX.1-2001.

NOTES
       A  child  process created via fork(2) inherits its parent's umask.  The
       umask is left unchanged by execve(2).

       The umask setting also affects the permissions assigned  to  POSIX  IPC
       objects  (mq_open(3), sem_open(3), shm_open(3)), FIFOs (mkfifo(3)), and
       UNIX domain sockets (unix(7)) created by the process.  The  umask  does
       not  affect the permissions assigned to System V IPC objects created by
       the process (using msgget(2), semget(2), shmget(2)).

SEE ALSO
       chmod(2), mkdir(2), open(2), stat(2), acl(5)

COLOPHON
       This page is part of release 4.00 of the Linux  man-pages  project.   A
       description  of  the project, information about reporting bugs, and the
       latest    version    of    this    page,    can     be     found     at
       http://www.kernel.org/doc/man-pages/.



Linux                             2016-04-13                          UMASK(2)

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

#1378220

On 04/13/16 12:05, Richard W.M. Jones wrote:
> v3 -> v4:
>
>   - Rename the syscall: getumask becomes umask2.
>
>   - Add flags parameter, with one flag (UMASK_GET_MASK).
>
>   - Expand the rationale for this change in the first commit message.
>
>
> 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 wouldn't say "if"; that is the case when it matters.

I have to say I'm skeptic to the need for umask2() as opposed to 
getumask().  I would also like to be able to get the umask of another 
process, which would argue for adding it to /proc anyway.

	-hpa

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

#1378285

* H. Peter Anvin:

> I have to say I'm skeptic to the need for umask2() as opposed to
> getumask().

I find the extension with a set-the-thread umask somewhat unlikely.
How would a potential per-thread umask interact with CLONE_FS?
Have a per-thread umask that, when active, overrides the global
one, similar to what uselocale provides?  That seems rather messy,
and I'm not aware of any precedent.

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

#1378287

On Wed, Apr 13, 2016 at 10:45:05PM +0200, Florian Weimer wrote:
> * H. Peter Anvin:
> 
> > I have to say I'm skeptic to the need for umask2() as opposed to
> > getumask().
> 
> I find the extension with a set-the-thread umask somewhat unlikely.
> How would a potential per-thread umask interact with CLONE_FS?
> Have a per-thread umask that, when active, overrides the global
> one, similar to what uselocale provides?  That seems rather messy,
> and I'm not aware of any precedent.

The flags parameter is for extensions we can't envisage now ...

... although since umask has been around since Unix V6 in 1978, we
might be waiting a long time.

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]

#1378333 — Re: [PATCH v4 0/3] vfs: Define new syscall umask2 [formerly getumask]

Hi Richard,

On Wed, 13 Apr 2016 20:05:33 +0100 "Richard W.M. Jones" <rjones@redhat.com> 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 was wondering if you really need to read the umask, or would just a
"ignore umask" flag to open{,at} do what you want?

-- 
Cheers,
Stephen Rothwell

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

#1378632

On Thu, Apr 14, 2016 at 09:09:38AM +1000, Stephen Rothwell wrote:
> Hi Richard,
> 
> On Wed, 13 Apr 2016 20:05:33 +0100 "Richard W.M. Jones" <rjones@redhat.com> 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 was wondering if you really need to read the umask, or would just a
> "ignore umask" flag to open{,at} do what you want?

This would be very useful, although I think being able to read umask
is also useful.

---

FWIW I am currently developing a patch to add umask to
/proc/PID/status.  Will post it shortly once I've tested it properly.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web