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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:38 UTC