public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Richard W.M. Jones" <rjones@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-kernel@vger.kernel.org, corbet@lwn.net,
	akpm@linux-foundation.org, vbabka@suse.cz, hughd@google.com,
	koct9i@gmail.com, chenhanxiao@cn.fujitsu.com,
	n-horiguchi@ah.jp.nec.com, ross.zwisler@linux.intel.com,
	john.stultz@linaro.org, minchan@kernel.org, jmarchan@redhat.com,
	hannes@cmpxchg.org, nathans@redhat.com,
	andriy.shevchenko@linux.intel.com, keescook@chromium.org,
	gorcunov@openvz.org, joe@perches.com, linux@rasmusvillemoes.dk,
	mingo@kernel.org, cmetcalf@ezchip.com, iago@endocode.com,
	luto@kernel.org, linux-doc@vger.kernel.org, gorcunov@gmail.com,
	fw@deneb.enyo.de, walters@verbum.org
Subject: Re: [PATCH v2] procfs: expose umask in /proc/<PID>/status
Date: Fri, 15 Apr 2016 14:29:52 +0100	[thread overview]
Message-ID: <20160415132952.GZ11600@redhat.com> (raw)
In-Reply-To: <20160415131309.GK32377@dhcp22.suse.cz>

On Fri, Apr 15, 2016 at 03:13:10PM +0200, Michal Hocko wrote:
> On Thu 14-04-16 12:08:15, 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.
> 
> It would be helpful to describe the usecase a bit better. Who needs to
> read the umask and what for (e.g. what if the umask changes right after
> it has been read by the 3rd party?).
> 
> I am not opposing the patch as is but this exports a new information to
> the userspace and we will have to maintain it for ever, so we should
> better describe the usecase.

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]

Rich.

> > 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.
> > 
> > Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
> > ---
> >  Documentation/filesystems/proc.txt |  1 +
> >  fs/proc/array.c                    | 20 +++++++++++++++++++-
> >  2 files changed, 20 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
> > index 7f5607a..e8d0075 100644
> > --- a/Documentation/filesystems/proc.txt
> > +++ b/Documentation/filesystems/proc.txt
> > @@ -225,6 +225,7 @@ Table 1-2: Contents of the status files (as of 4.1)
> >   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 --git a/fs/proc/array.c b/fs/proc/array.c
> > index b6c00ce..88c7de1 100644
> > --- a/fs/proc/array.c
> > +++ b/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(struct task_struct *tsk)
> >  	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_file *m, struct pid_namespace *ns,
> >  	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;
> > -- 
> > 2.7.4
> 
> -- 
> Michal Hocko
> SUSE Labs

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

  reply	other threads:[~2016-04-15 13:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-14 11:08 [PATCH v2] procfs: expose umask in /proc/<PID>/status Richard W.M. Jones
2016-04-14 11:08 ` Richard W.M. Jones
2016-04-14 12:34   ` Konstantin Khlebnikov
2016-04-14 12:41   ` Jerome Marchand
2016-04-15 13:13   ` Michal Hocko
2016-04-15 13:29     ` Richard W.M. Jones [this message]
2016-04-15 15:52       ` Theodore Ts'o
2016-04-15 16:43   ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160415132952.GZ11600@redhat.com \
    --to=rjones@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=chenhanxiao@cn.fujitsu.com \
    --cc=cmetcalf@ezchip.com \
    --cc=corbet@lwn.net \
    --cc=fw@deneb.enyo.de \
    --cc=gorcunov@gmail.com \
    --cc=gorcunov@openvz.org \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=iago@endocode.com \
    --cc=jmarchan@redhat.com \
    --cc=joe@perches.com \
    --cc=john.stultz@linaro.org \
    --cc=keescook@chromium.org \
    --cc=koct9i@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=luto@kernel.org \
    --cc=mhocko@kernel.org \
    --cc=minchan@kernel.org \
    --cc=mingo@kernel.org \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=nathans@redhat.com \
    --cc=ross.zwisler@linux.intel.com \
    --cc=vbabka@suse.cz \
    --cc=walters@verbum.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox