Date: Fri, 30 Aug 2013 12:03:41 -0600 From: Jamie Gritton <jamie@FreeBSD.org> To: Jase Thew <jase@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r252841 - in head/sys: dev/mem kern sys Message-ID: <5220DE7D.5000806@FreeBSD.org> In-Reply-To: <5220D2D5.6030105@FreeBSD.org> References: <201307052131.r65LVGKr089550@svn.freebsd.org> <5220D2D5.6030105@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/30/13 11:13, Jase Thew wrote: > On 05/07/2013 22:31, Jamie Gritton wrote: >> Author: jamie >> Date: Fri Jul 5 21:31:16 2013 >> New Revision: 252841 >> URL: http://svnweb.freebsd.org/changeset/base/252841 >> >> Log: >> Add new privileges, PRIV_KMEM_READ and PRIV_KMEM_WRITE, used in >> opening >> /dev/kmem and /dev/mem (in addition to traditional file permission >> checks). >> PRIV_KMEM_READ is different from other PRIV_* checks in that it's >> allowed >> by default. >> >> Reviewed by: kib, mckusick >> > > Hi Jamie, > > As a result of this commit (and r252845), it is no longer possible to > access /dev/mem and /dev/kmem inside of a jail - is this behaviour > intentional? > > # dd if=/dev/mem bs=64 count=1 > dd: /dev/mem: Operation not permitted It's intentional, but it's not intended to be the full solution. I also need to add a permission flag to jails to allow kmem access. However I didn't intend to disrupt read permission, though clearly it does since it now passes through prison_priv_check. So I ought to add some code in prison_priv_check that mirrors the code in priv_check_cred to allow PRIV_KMEM_READ by default. - Jamie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5220DE7D.5000806>