From owner-freebsd-current@FreeBSD.ORG Sun Jun 16 22:49:00 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2C524B70; Sun, 16 Jun 2013 22:49:00 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) by mx1.freebsd.org (Postfix) with ESMTP id 066181D10; Sun, 16 Jun 2013 22:48:59 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id r5GMmvk5021473; Sun, 16 Jun 2013 15:48:57 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201306162248.r5GMmvk5021473@chez.mckusick.com> To: Jamie Gritton Subject: Re: A PRIV_* flag for /dev/mem? In-reply-to: <51BCF786.2070603@FreeBSD.org> Date: Sun, 16 Jun 2013 15:48:57 -0700 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com X-Mailman-Approved-At: Sun, 16 Jun 2013 23:48:05 +0000 Cc: Konstantin Belousov , Robert Watson , FreeBSD Current , Alexander Leidinger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jun 2013 22:49:00 -0000 > Date: Sat, 15 Jun 2013 17:23:50 -0600 > From: Jamie Gritton > To: FreeBSD Current > CC: Kirk McKusick , > Konstantin Belousov , > Alexander Leidinger , > Pawel Jakub Dawidek , > Robert Watson > Subject: Re: A PRIV_* flag for /dev/mem? > > On 05/20/13 16:56, Kirk McKusick wrote: >> I pointed Robert and Pawel at your discussion on creating a new >> PRIV_KMEM and adding a check for it in memopen(). I am of the opinion >> that this is a good idea, but I am hoping that one of Robert or Pawel >> will comment since they are much more active in this area. > > I suppose it's safe to say further comment isn't forthcoming. So with > one vote for and one against (or at least questioning), I'll humbly > leave it up to myself to be the tie-breaker :-). > > Here's a proposed patch. I separate kmem access into read and write, as > I saw other similar splits in the priv list. Perhaps that's overkill, > and I can use a single PRIV_KMEM instead of PRIV_KMEM_READ and > PRIV_KMEM_WRITE. > > Perhaps this is an overreach, because PRIV_KMEM_READ is used where the > default isn't root privilege: the file permission and expected usage are > group kmem gets to read /dev/[k]mem. I'm not about to go hard-coding a > gid into the kernel, so it seems the proper thing to do (not included in > the patch) would be to allow PRIV_KMEM_READ by default. I thought there > might already be such cases where the default is to allow, but no: this > would be the first default-allow permission. So perhaps the best answer > is not worry about that one, and only add PRIV_KMEM_WRITE (leaving reads > controlled by file permission alone as they are now). > > - Jamie With the change from the error noted by Kostik, I concur with your proposed change. Kirk McKusick