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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
