Re: A PRIV_* flag for /dev/mem?

> Date: Sat, 15 Jun 2013 17:23:50 -0600
> From: Jamie Gritton <jamie_at_FreeBSD.org>
> To: FreeBSD Current <freebsd-current_at_FreeBSD.org>
> CC: Kirk McKusick <mckusick_at_mckusick.com>,
>         Konstantin Belousov <kostikbel_at_gmail.com>,
>         Alexander Leidinger <netchild_at_FreeBSD.org>,
>         Pawel Jakub Dawidek <pjd_at_FreeBSD.org>,
>         Robert Watson <rwatson_at_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