svn commit: r232181 - in head/sys: kern sys
trociny at freebsd.org
Wed Feb 29 07:50:52 UTC 2012
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
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
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.
More information about the svn-src-all