From owner-svn-src-head@FreeBSD.ORG Wed Feb 29 13:25:17 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A1881065672; Wed, 29 Feb 2012 13:25:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 446AA8FC18; Wed, 29 Feb 2012 13:25:16 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1TDP8MJ095279; Wed, 29 Feb 2012 15:25:08 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1TDP7sO095290; Wed, 29 Feb 2012 15:25:07 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1TDP793095289; Wed, 29 Feb 2012 15:25:07 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 29 Feb 2012 15:25:07 +0200 From: Konstantin Belousov To: Mikolaj Golub Message-ID: <20120229132507.GB55074@deviant.kiev.zoral.com.ua> 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> <9557FCA0-7428-4794-8A27-9888F42974CA@freebsd.org> <86mx81byt6.fsf@in138.ua3> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BLc7wQ/ocIv/2Jnx" Content-Disposition: inline In-Reply-To: <86mx81byt6.fsf@in138.ua3> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: src-committers@freebsd.org, Pawel Jakub Dawidek , svn-src-all@freebsd.org, svn-src-head@freebsd.org, "Robert N. M. Watson" , Konstantin Belousov , Julian Elischer Subject: Re: svn commit: r232181 - in head/sys: kern sys X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 13:25:17 -0000 --BLc7wQ/ocIv/2Jnx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 29, 2012 at 02:37:25PM +0200, Mikolaj Golub wrote: >=20 > On Wed, 29 Feb 2012 12:03:00 +0000 Robert N. M. Watson wrote: >=20 > RNMW> I think the monitoring aspect of the patch is fine. >=20 > RNMW> The bit I was worried about was external umask changes. This can c= ause > RNMW> race conditions for applications that manage their umask -- for > RNMW> example, bsdtar, if I recall correctly. It's one thing to use a > RNMW> debugger to force an application to change its umask -- the develo= per > RNMW> needs to know they are changing application behaviour. But exposin= g a > RNMW> feature that can lead to correct applications but incorrect result= s is > RNMW> a risky thing to do, hence my objection. >=20 > RNMW> I think given the other objections, it would be wise to remove wri= te > RNMW> access to process umasks, but retain read access for procstat (whi= ch is > RNMW> quite useful, I agree). >=20 > I still don't see why having a sysctl RW is worse than asking users to run > something like in the attach when they need to change umask for another > process, but ok, if people don't like RW I will remove it. >=20 What is done is attach is much worse then the sysctl, just because debugger attach often causes spurious EINTR, indeed seriously disrupting applications, as opposed to some uncertain damage that could be done in theory. *shrug* --BLc7wQ/ocIv/2Jnx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9OJzIACgkQC3+MBN1Mb4jPdwCfWaju5cIqfcqalflDzQgHP56X lZAAn2KukOrLxcDEbZHWuAiKx/vQcg5/ =gYNz -----END PGP SIGNATURE----- --BLc7wQ/ocIv/2Jnx--