Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751780AbcDOPxE (ORCPT <rfc822;w@1wt.eu>);
	Fri, 15 Apr 2016 11:53:04 -0400
Received: from imap.thunk.org ([74.207.234.97]:60098 "EHLO imap.thunk.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750970AbcDOPxB (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 15 Apr 2016 11:53:01 -0400
Date: Fri, 15 Apr 2016 11:52:25 -0400
From: "Theodore Ts'o" <tytso@mit.edu>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: Michal Hocko <mhocko@kernel.org>, 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
Message-ID: <20160415155225.GD11838@thunk.org>
Mail-Followup-To: Theodore Ts'o <tytso@mit.edu>,
	"Richard W.M. Jones" <rjones@redhat.com>,
	Michal Hocko <mhocko@kernel.org>, 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
References: <1460632095-434-1-git-send-email-rjones@redhat.com>
 <1460632095-434-2-git-send-email-rjones@redhat.com>
 <20160415131309.GK32377@dhcp22.suse.cz>
 <20160415132952.GZ11600@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160415132952.GZ11600@redhat.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1313
Lines: 30

On Fri, Apr 15, 2016 at 02:29:52PM +0100, Richard W.M. Jones wrote:
> 
> 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]

I think /proc is better because it's already pretty well understood
that programs like "ps" returns information which is subject to
change, even before the ps command has had a chance to print the
values.  Where as I could easily see programmers who read umask via a
system call could more easily get confused about the expectations of
stability of the returned value.  (This is not a strong argument,
admittedly, because the same stupid application programmer could get
confused about the stability of getuid() as well.)

The stronger argument IMHO is that you're not at the mercy of glibc
developers to add it to glibc.

					- Ted