From owner-svn-src-all@FreeBSD.ORG Wed Feb 29 07:50:52 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEB801065672; Wed, 29 Feb 2012 07:50:52 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 66AAF8FC16; Wed, 29 Feb 2012 07:50:51 +0000 (UTC) Received: by eekd17 with SMTP id d17so2181563eek.13 for ; Tue, 28 Feb 2012 23:50:50 -0800 (PST) Received-SPF: pass (google.com: domain of to.my.trociny@gmail.com designates 10.213.20.19 as permitted sender) client-ip=10.213.20.19; Authentication-Results: mr.google.com; spf=pass (google.com: domain of to.my.trociny@gmail.com designates 10.213.20.19 as permitted sender) smtp.mail=to.my.trociny@gmail.com; dkim=pass header.i=to.my.trociny@gmail.com Received: from mr.google.com ([10.213.20.19]) by 10.213.20.19 with SMTP id d19mr326667ebb.37.1330501850388 (num_hops = 1); Tue, 28 Feb 2012 23:50:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:organization:references:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=YukvTL0m9QDPPhrapHkR8DaKHCz/VX8u6mAL6mQh+Xg=; b=kx052zZYDIc8ICCI6JZsRDtwTZ/BKcbGk8JvMdM6JC9fURteDP1I0BhI64TV0R/W0H mgYj4M0uYHYWkdjqaQrgJa39icixDlN56bD1qijzqBdYul10EkMNzX6Ab1nP24trC7Kw zUd9ABWA0hWL+IXQ+ibdFyWQmHL5IIdYhZul4= Received: by 10.213.20.19 with SMTP id d19mr279731ebb.37.1330501850248; Tue, 28 Feb 2012 23:50:50 -0800 (PST) Received: from localhost ([94.27.39.186]) by mx.google.com with ESMTPS id i10sm39898463eea.8.2012.02.28.23.50.46 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Feb 2012 23:50:47 -0800 (PST) From: Mikolaj Golub To: Julian Elischer Organization: TOA Ukraine 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> Sender: Mikolaj Golub Date: Wed, 29 Feb 2012 09:50:44 +0200 In-Reply-To: <4F4D6AA4.9040208@freebsd.org> (Julian Elischer's message of "Tue, 28 Feb 2012 16:00:36 -0800") Message-ID: <86vcmqaxij.fsf@in138.ua3> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: src-committers@freebsd.org, Pawel Jakub Dawidek , svn-src-all@freebsd.org, svn-src-head@freebsd.org, Robert Watson , Konstantin Belousov 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 07:50:52 -0000 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