Date: Wed, 29 Feb 2012 12:03:00 +0000 From: "Robert N. M. Watson" <rwatson@freebsd.org> To: Mikolaj Golub <trociny@freebsd.org> Cc: src-committers@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Konstantin Belousov <kostikbel@gmail.com>, Julian Elischer <julian@freebsd.org> Subject: Re: svn commit: r232181 - in head/sys: kern sys Message-ID: <9557FCA0-7428-4794-8A27-9888F42974CA@freebsd.org> In-Reply-To: <86vcmqaxij.fsf@in138.ua3> References: <201202261425.q1QEPm9g069102@svn.freebsd.org> <20120227082811.GC1363@garage.freebsd.pl> <864nucd5jc.fsf@in138.ua3> <20120227092951.GB55074@deviant.kiev.zoral.com.ua> <4F4C7571.7010407@freebsd.org> <86zkc3bell.fsf@in138.ua3> <4F4D6AA4.9040208@freebsd.org> <86vcmqaxij.fsf@in138.ua3>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9557FCA0-7428-4794-8A27-9888F42974CA>