linux-kernel - Re: [PATCH v2] procfs: expose umask in /proc/<PID>/status

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160415155225.GD11838@thunk.org>
Date:	Fri, 15 Apr 2016 11:52:25 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	"Richard W.M. Jones" <rjones@...hat.com>
Cc:	Michal Hocko <mhocko@...nel.org>, linux-kernel@...r.kernel.org,
	corbet@....net, akpm@...ux-foundation.org, vbabka@...e.cz,
	hughd@...gle.com, koct9i@...il.com, chenhanxiao@...fujitsu.com,
	n-horiguchi@...jp.nec.com, ross.zwisler@...ux.intel.com,
	john.stultz@...aro.org, minchan@...nel.org, jmarchan@...hat.com,
	hannes@...xchg.org, nathans@...hat.com,
	andriy.shevchenko@...ux.intel.com, keescook@...omium.org,
	gorcunov@...nvz.org, joe@...ches.com, linux@...musvillemoes.dk,
	mingo@...nel.org, cmetcalf@...hip.com, iago@...ocode.com,
	luto@...nel.org, linux-doc@...r.kernel.org, gorcunov@...il.com,
	fw@...eb.enyo.de, walters@...bum.org
Subject: Re: [PATCH v2] procfs: expose umask in /proc/<PID>/status

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