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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
