A PRIV_* flag for /dev/mem?
mckusick at mckusick.com
Sun Jun 16 22:49:00 UTC 2013
> 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
> 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
More information about the freebsd-current