Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 16 Jun 2013 15:48:57 -0700
From:      Kirk McKusick <mckusick@mckusick.com>
To:        Jamie Gritton <jamie@FreeBSD.org>
Cc:        Konstantin Belousov <kostikbel@gmail.com>, Robert Watson <rwatson@FreeBSD.org>, FreeBSD Current <freebsd-current@FreeBSD.org>, Alexander Leidinger <netchild@FreeBSD.org>
Subject:   Re: A PRIV_* flag for /dev/mem? 
Message-ID:  <201306162248.r5GMmvk5021473@chez.mckusick.com>
In-Reply-To: <51BCF786.2070603@FreeBSD.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Sat, 15 Jun 2013 17:23:50 -0600
> From: Jamie Gritton <jamie@FreeBSD.org>
> To: FreeBSD Current <freebsd-current@FreeBSD.org>
> CC: Kirk McKusick <mckusick@mckusick.com>,
>         Konstantin Belousov <kostikbel@gmail.com>,
>         Alexander Leidinger <netchild@FreeBSD.org>,
>         Pawel Jakub Dawidek <pjd@FreeBSD.org>,
>         Robert Watson <rwatson@FreeBSD.org>
> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201306162248.r5GMmvk5021473>