From owner-svn-src-all@FreeBSD.ORG Wed Feb 29 12:03:06 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 894A11065676; Wed, 29 Feb 2012 12:03:06 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5B94E8FC18; Wed, 29 Feb 2012 12:03:06 +0000 (UTC) Received: from c0147.aw.cl.cam.ac.uk (c0147.aw.cl.cam.ac.uk [128.232.100.147]) by cyrus.watson.org (Postfix) with ESMTPSA id 4836E46B0A; Wed, 29 Feb 2012 07:03:05 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <86vcmqaxij.fsf@in138.ua3> Date: Wed, 29 Feb 2012 12:03:00 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9557FCA0-7428-4794-8A27-9888F42974CA@freebsd.org> 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> To: Mikolaj Golub X-Mailer: Apple Mail (2.1257) Cc: src-committers@freebsd.org, Pawel Jakub Dawidek , svn-src-all@freebsd.org, svn-src-head@freebsd.org, Konstantin Belousov , Julian Elischer Subject: Re: svn commit: r232181 - in head/sys: kern sys X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 12:03:06 -0000 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=