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_______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
