svn commit: r232181 - in head/sys: kern sys

[Robert N. M. Watson]

On 29 Feb 2012, at 07:50, Mikolaj Golub wrote:

> JE> well that's exactly what I AM questioning..  how often will this be used?
> JE> one person using this once in all of history isn't a real requirement
> JE> for inclusion.
> 
> This information may be very useful when troubleshooting unexpected behavior
> of the application.
> 
> Dmitry Banschikov, who was asking for this functionality and eventually
> provided the patch, said that it needed this investigating an issue with an
> application which created files with unexpected permissions. It turned out the
> issue was with wrong usage of su(1), which may interpret '-c' option as a
> login class or as a command to run, so the umask specified in the login class
> was not applied. Then it wrote an utility to read a process umask via kvm to
> troubleshoot this.
> 
> I don't think this situation is in the class "one person using this once in
> all of history".
> 
> In my practice I have not face a situation when I need to know umask of
> another process and it will be good if I never need this. But if I need it
> eventually I would like to have a quick and easy way to do this.
> 
> Also for me after applying the patch 'procstat -sa' output on my hosts was
> rather educational.
> 
> JE> It seems to me that someone is more likely to figure out a sneaky way
> JE> to use this in a bad way than to want to use it in the way you expect.
> 
> Being this someone I would use much easier sneaky ways to make a mess for
> processes running with my uid.

I think the monitoring aspect of the patch is fine.

The bit I was worried about was external umask changes. This can cause race conditions for applications that manage their umask -- for example, bsdtar, if I recall correctly. It's one thing to use a debugger to force an application to change its umask -- the developer needs to know they are changing application behaviour. But exposing a feature that can lead to correct applications but incorrect results is a risky thing to do, hence my objection.

I think given the other objections, it would be wise to remove write access to process umasks, but retain read access for procstat (which is quite useful, I agree).

Robert