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. >=20 > This information may be very useful when troubleshooting unexpected = behavior > of the application. >=20 > 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. >=20 > I don't think this situation is in the class "one person using this = once in > all of history". >=20 > 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. >=20 > Also for me after applying the patch 'procstat -sa' output on my hosts = was > rather educational. >=20 > 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. >=20 > 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>