A PRIV_* flag for /dev/mem?

Jamie Gritton jamie at FreeBSD.org
Sat Jun 15 23:27:22 UTC 2013


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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kmem.diff
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20130615/ca57809f/attachment.ksh>


More information about the freebsd-current mailing list