Date: Wed, 29 Feb 2012 09:50:44 +0200 From: Mikolaj Golub <trociny@freebsd.org> To: Julian Elischer <julian@freebsd.org> Cc: src-committers@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Robert Watson <rwatson@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com> Subject: Re: svn commit: r232181 - in head/sys: kern sys Message-ID: <86vcmqaxij.fsf@in138.ua3> In-Reply-To: <4F4D6AA4.9040208@freebsd.org> (Julian Elischer's message of "Tue, 28 Feb 2012 16:00:36 -0800") 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 Feb 2012 16:00:36 -0800 Julian Elischer wrote: JE> On 2/27/12 11:29 PM, Mikolaj Golub wrote: >> On Mon, 27 Feb 2012 22:34:25 -0800 Julian Elischer wrote: >> >> JE> I don't think this belongs in the kernel by default. It's not exactl a >> JE> call for backout but It's teh next thing short of that. a call for "do >> JE> you REALLY think we need this particular specific case catered for?" >> >> The main goal of the patch was to provide ability to get another process >> umask. It looks like usefulness of this is not questioned here. 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. -- Mikolaj Golub
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86vcmqaxij.fsf>