+ procfs-expose-umask-in-proc-pid-status.patch added to -mm tree

+ procfs-expose-umask-in-proc-pid-status.patch added to -mm tree

[akpm]

The patch titled
     Subject: procfs: expose umask in /proc/<PID>/status
has been added to the -mm tree.  Its filename is
     procfs-expose-umask-in-proc-pid-status.patch

This patch should soon appear at
    http://ozlabs.org/~akpm/mmots/broken-out/procfs-expose-umask-in-proc-pid-status.patch
and later at
    http://ozlabs.org/~akpm/mmotm/broken-out/procfs-expose-umask-in-proc-pid-status.patch

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/SubmitChecklist when testing your code ***

The -mm tree is included into linux-next and is updated
there every 3-4 working days

------------------------------------------------------
From: "Richard W.M. Jones" <rjones@redhat.com>
Subject: procfs: expose umask in /proc/<PID>/status

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.

Add a new status line ("Umask") in /proc/<PID>/status.  It contains
the file mode creation mask (umask) in octal.  It is only shown for
tasks which have task->fs.

This patch is adapted from one originally written by Pierre Carrier.


The use case is that we have endless trouble with people setting weird
umask() values (usually on the grounds of "security"), and then everything
breaking.  I'm on the hook to fix these.  We'd like to add debugging to
our program so we can dump out the umask in debug reports.

Previous versions of the patch used a syscall so you could only read your
own umask.  That's all I need.  However there was quite a lot of push-back
from those, so this new version exports it in /proc.

See:

https://lkml.org/lkml/2016/4/13/704 [umask2]
https://lkml.org/lkml/2016/4/13/487 [getumask]
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Acked-by: Konstantin Khlebnikov <koct9i@gmail.com>
Acked-by: Jerome Marchand <jmarchan@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Pierre Carrier <pierre@spotify.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 Documentation/filesystems/proc.txt |    1 +
 fs/proc/array.c                    |   20 +++++++++++++++++++-
 2 files changed, 20 insertions(+), 1 deletion(-)

diff -puN Documentation/filesystems/proc.txt~procfs-expose-umask-in-proc-pid-status Documentation/filesystems/proc.txt
--- a/Documentation/filesystems/proc.txt~procfs-expose-umask-in-proc-pid-status
+++ a/Documentation/filesystems/proc.txt
@@ -225,6 +225,7 @@ Table 1-2: Contents of the status files
  TracerPid                   PID of process tracing this process (0 if not)
  Uid                         Real, effective, saved set, and  file system UIDs
  Gid                         Real, effective, saved set, and  file system GIDs
+ Umask                       file mode creation mask
  FDSize                      number of file descriptor slots currently allocated
  Groups                      supplementary group list
  NStgid                      descendant namespace thread group ID hierarchy
diff -puN fs/proc/array.c~procfs-expose-umask-in-proc-pid-status fs/proc/array.c
--- a/fs/proc/array.c~procfs-expose-umask-in-proc-pid-status
+++ a/fs/proc/array.c
@@ -83,6 +83,7 @@
 #include <linux/tracehook.h>
 #include <linux/string_helpers.h>
 #include <linux/user_namespace.h>
+#include <linux/fs_struct.h>
 
 #include <asm/pgtable.h>
 #include <asm/processor.h>
@@ -139,12 +140,25 @@ static inline const char *get_task_state
 	return task_state_array[fls(state)];
 }
 
+static inline int get_task_umask(struct task_struct *tsk)
+{
+	struct fs_struct *fs;
+	int umask = -ENOENT;
+
+	task_lock(tsk);
+	fs = tsk->fs;
+	if (fs)
+		umask = fs->umask;
+	task_unlock(tsk);
+	return umask;
+}
+
 static inline void task_state(struct seq_file *m, struct pid_namespace *ns,
 				struct pid *pid, struct task_struct *p)
 {
 	struct user_namespace *user_ns = seq_user_ns(m);
 	struct group_info *group_info;
-	int g;
+	int g, umask;
 	struct task_struct *tracer;
 	const struct cred *cred;
 	pid_t ppid, tpid = 0, tgid, ngid;
@@ -162,6 +176,10 @@ static inline void task_state(struct seq
 	ngid = task_numa_group_id(p);
 	cred = get_task_cred(p);
 
+	umask = get_task_umask(p);
+	if (umask >= 0)
+		seq_printf(m, "Umask:\t%#04o\n", umask);
+
 	task_lock(p);
 	if (p->files)
 		max_fds = files_fdtable(p->files)->max_fds;
_

Patches currently in -mm which might be from rjones@redhat.com are

procfs-expose-umask-in-proc-pid-status.patch

Re: + procfs-expose-umask-in-proc-pid-status.patch added to -mm tree

[Michal Hocko]

Just a formal note from me here.

On Fri 22-04-16 13:54:36, Andrew Morton wrote:
> From: "Richard W.M. Jones" <rjones@redhat.com>
> Subject: procfs: expose umask in /proc/<PID>/status
> 
> 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.
> 
> Add a new status line ("Umask") in /proc/<PID>/status.  It contains
> the file mode creation mask (umask) in octal.  It is only shown for
> tasks which have task->fs.
> 
> This patch is adapted from one originally written by Pierre Carrier.
> 
> 
> The use case is that we have endless trouble with people setting weird
> umask() values (usually on the grounds of "security"), and then everything
> breaking.  I'm on the hook to fix these.  We'd like to add debugging to
> our program so we can dump out the umask in debug reports.
> 
> Previous versions of the patch used a syscall so you could only read your
> own umask.  That's all I need.  However there was quite a lot of push-back
> from those, so this new version exports it in /proc.
> 
> See:
> 

lkmlo.org links tend to be rather unstable from my experience. Please
try to use lkml.kernel.org/[rg]/$msg_id as much as possible

> https://lkml.org/lkml/2016/4/13/704 [umask2]

http://lkml.kernel.org/r/1460574336-18930-1-git-send-email-rjones@redhat.com

> https://lkml.org/lkml/2016/4/13/487 [getumask]

http://lkml.kernel.org/r/1460547786-16766-1-git-send-email-rjones@redhat.com

> Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
> Acked-by: Konstantin Khlebnikov <koct9i@gmail.com>
> Acked-by: Jerome Marchand <jmarchan@redhat.com>
> Acked-by: Kees Cook <keescook@chromium.org>
> Cc: "Theodore Ts'o" <tytso@mit.edu>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Pierre Carrier <pierre@spotify.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  Documentation/filesystems/proc.txt |    1 +
>  fs/proc/array.c                    |   20 +++++++++++++++++++-
>  2 files changed, 20 insertions(+), 1 deletion(-)
> 
> diff -puN Documentation/filesystems/proc.txt~procfs-expose-umask-in-proc-pid-status Documentation/filesystems/proc.txt
> --- a/Documentation/filesystems/proc.txt~procfs-expose-umask-in-proc-pid-status
> +++ a/Documentation/filesystems/proc.txt
> @@ -225,6 +225,7 @@ Table 1-2: Contents of the status files
>   TracerPid                   PID of process tracing this process (0 if not)
>   Uid                         Real, effective, saved set, and  file system UIDs
>   Gid                         Real, effective, saved set, and  file system GIDs
> + Umask                       file mode creation mask
>   FDSize                      number of file descriptor slots currently allocated
>   Groups                      supplementary group list
>   NStgid                      descendant namespace thread group ID hierarchy
> diff -puN fs/proc/array.c~procfs-expose-umask-in-proc-pid-status fs/proc/array.c
> --- a/fs/proc/array.c~procfs-expose-umask-in-proc-pid-status
> +++ a/fs/proc/array.c
> @@ -83,6 +83,7 @@
>  #include <linux/tracehook.h>
>  #include <linux/string_helpers.h>
>  #include <linux/user_namespace.h>
> +#include <linux/fs_struct.h>
>  
>  #include <asm/pgtable.h>
>  #include <asm/processor.h>
> @@ -139,12 +140,25 @@ static inline const char *get_task_state
>  	return task_state_array[fls(state)];
>  }
>  
> +static inline int get_task_umask(struct task_struct *tsk)
> +{
> +	struct fs_struct *fs;
> +	int umask = -ENOENT;
> +
> +	task_lock(tsk);
> +	fs = tsk->fs;
> +	if (fs)
> +		umask = fs->umask;
> +	task_unlock(tsk);
> +	return umask;
> +}
> +
>  static inline void task_state(struct seq_file *m, struct pid_namespace *ns,
>  				struct pid *pid, struct task_struct *p)
>  {
>  	struct user_namespace *user_ns = seq_user_ns(m);
>  	struct group_info *group_info;
> -	int g;
> +	int g, umask;
>  	struct task_struct *tracer;
>  	const struct cred *cred;
>  	pid_t ppid, tpid = 0, tgid, ngid;
> @@ -162,6 +176,10 @@ static inline void task_state(struct seq
>  	ngid = task_numa_group_id(p);
>  	cred = get_task_cred(p);
>  
> +	umask = get_task_umask(p);
> +	if (umask >= 0)
> +		seq_printf(m, "Umask:\t%#04o\n", umask);
> +
>  	task_lock(p);
>  	if (p->files)
>  		max_fds = files_fdtable(p->files)->max_fds;
> _
> 
> Patches currently in -mm which might be from rjones@redhat.com are
> 
> procfs-expose-umask-in-proc-pid-status.patch

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: + procfs-expose-umask-in-proc-pid-status.patch added to -mm tree

[Richard W.M. Jones]

On Mon, Apr 25, 2016 at 11:31:55AM +0200, Michal Hocko wrote:
> On Fri 22-04-16 13:54:36, Andrew Morton wrote:
> > From: "Richard W.M. Jones" <rjones@redhat.com>
> > Subject: procfs: expose umask in /proc/<PID>/status
> > 
> > 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.
> > 
> > Add a new status line ("Umask") in /proc/<PID>/status.  It contains
> > the file mode creation mask (umask) in octal.  It is only shown for
> > tasks which have task->fs.
> > 
> > This patch is adapted from one originally written by Pierre Carrier.
> > 
> > 
> > The use case is that we have endless trouble with people setting weird
> > umask() values (usually on the grounds of "security"), and then everything
> > breaking.  I'm on the hook to fix these.  We'd like to add debugging to
> > our program so we can dump out the umask in debug reports.
> > 
> > Previous versions of the patch used a syscall so you could only read your
> > own umask.  That's all I need.  However there was quite a lot of push-back
> > from those, so this new version exports it in /proc.
> > 
> > See:
> > 
> 
> lkmlo.org links tend to be rather unstable from my experience. Please
> try to use lkml.kernel.org/[rg]/$msg_id as much as possible
> 
> > https://lkml.org/lkml/2016/4/13/704 [umask2]
> 
> http://lkml.kernel.org/r/1460574336-18930-1-git-send-email-rjones@redhat.com
> 
> > https://lkml.org/lkml/2016/4/13/487 [getumask]
> 
> http://lkml.kernel.org/r/1460547786-16766-1-git-send-email-rjones@redhat.com

FWIW this was heavily edited from my original commit message.  My
original commit message (minus the Signed-off-by etc) was:

    procfs: expose umask in /proc/<PID>/status
    
    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.
    
    Add a new status line ("Umask") in /proc/<PID>/status.  It contains
    the file mode creation mask (umask) in octal.  It is only shown for
    tasks which have task->fs.
    
    This patch is adapted from one originally written by Pierre Carrier.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: + procfs-expose-umask-in-proc-pid-status.patch added to -mm tree

[Michal Hocko]

On Mon 25-04-16 13:12:19, Richard W.M. Jones wrote:
> On Mon, Apr 25, 2016 at 11:31:55AM +0200, Michal Hocko wrote:
> > On Fri 22-04-16 13:54:36, Andrew Morton wrote:
> > > From: "Richard W.M. Jones" <rjones@redhat.com>
> > > Subject: procfs: expose umask in /proc/<PID>/status
> > > 
> > > 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.
> > > 
> > > Add a new status line ("Umask") in /proc/<PID>/status.  It contains
> > > the file mode creation mask (umask) in octal.  It is only shown for
> > > tasks which have task->fs.
> > > 
> > > This patch is adapted from one originally written by Pierre Carrier.
> > > 
> > > 
> > > The use case is that we have endless trouble with people setting weird
> > > umask() values (usually on the grounds of "security"), and then everything
> > > breaking.  I'm on the hook to fix these.  We'd like to add debugging to
> > > our program so we can dump out the umask in debug reports.
> > > 
> > > Previous versions of the patch used a syscall so you could only read your
> > > own umask.  That's all I need.  However there was quite a lot of push-back
> > > from those, so this new version exports it in /proc.
> > > 
> > > See:
> > > 
> > 
> > lkmlo.org links tend to be rather unstable from my experience. Please
> > try to use lkml.kernel.org/[rg]/$msg_id as much as possible
> > 
> > > https://lkml.org/lkml/2016/4/13/704 [umask2]
> > 
> > http://lkml.kernel.org/r/1460574336-18930-1-git-send-email-rjones@redhat.com
> > 
> > > https://lkml.org/lkml/2016/4/13/487 [getumask]
> > 
> > http://lkml.kernel.org/r/1460547786-16766-1-git-send-email-rjones@redhat.com
> 
> FWIW this was heavily edited from my original commit message.  My
> original commit message (minus the Signed-off-by etc) was:
> 
>     procfs: expose umask in /proc/<PID>/status
>     
>     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.
>     
>     Add a new status line ("Umask") in /proc/<PID>/status.  It contains
>     the file mode creation mask (umask) in octal.  It is only shown for
>     tasks which have task->fs.
>     
>     This patch is adapted from one originally written by Pierre Carrier.

I guess Andrew added the remaining and I agree that part is really
useful. Any API to the userspace should document the use case. We have
added just way too many of those in the past without proper
justification. It is hard (close to impossible for some) to find out
what was the original reason why they were introduce and whether a small
change might break anything. Reference to discussions which shape the
API is useful as well.

Just my 2c
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>