Re: A PRIV_* flag for /dev/mem?
--CMLD6V24WUS0oql+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, May 17, 2013 at 01:14:23PM -0600, Jamie Gritton wrote:
> I'm considering Alexander Leidinger's patch to make X11 work inside a=20
> jail (http://leidinger.net/FreeBSD/current-patches/0_jail.diff). It=20
> allows a jail to optionally have access to /dev/io and DRI (provided the=
=20
> requisite device files are visible in the devfs ruleset).
>=20
> I'm planning on putting this under a single jail permission, which would=
=20
> group those two together as device access that allows messing with=20
> kernel memory. It seems more complete to put /dev/mem under that same=20
> umbrella, with the side benefit of letting me call it "allow.dev_mem".
>=20
> Currently, access is controlled only by device file permission and a=20
> securelevel check. Jail access is allowed as long as the /dev/mem is in=
=20
> the jail's ruleset (it isn't by default). Adding a prison_priv_check()=
=20
> call would allow some finer control over this. Something like:
>=20
> int
> memopen(struct cdev *dev __unused, int flags, int fmt __unused,
> struct thread *td)
> {
> int error;
>=20
> error =3D priv_check(td, PRIV_FOO);
> if (error !=3D 0 && (flags & FWRITE))
> error =3D securelevel_gt(td->td_ucred, 0);
>=20
> return (error);
> }
>=20
> The main question I'm coming up with here is, what PRIV_* flag should I=
=20
> use. Does PRIV_IO make sense? PRIV_DRIVER? Something new like=20
> PRIV_KMEM? Also, I'd appreciate if anyone familiar with this interface=
=20
> can tell me if memopen() is the right/only place to make this change.
Why do we need the PRIV check there at all, esp. for DRM ?
Why the devfs rulesets are not enough ?
--CMLD6V24WUS0oql+
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (FreeBSD)
iQIcBAEBAgAGBQJRl2l8AAoJEJDCuSvBvK1BjZ4P/2Rpm3WanpPgu58qgTXioyeq
J+3aQC4FfdILx9rggYjb4CQjyH5dngKV8IUpT0HPXrzar8XSz++crRbtFA7lvvOs
yjIUYswmxWC0sen6iItq+njiBaYo5oLqVatY5HmQAdC+MOPO1Ei5Qoc6Cf4H7uJ0
GmbGb3mGSSGyoAi3Uamp9UEAHP3XgHbTB4nzr8bsZO1iZbzAunklTcQVhPSe8zTO
+iQ7mbhDWkzhUye7kxtMJPaNMoSUduaeU+KHzm6vkRsK76wn1EMLVz9R7jaDMDmw
bSl88V49gxJ3RpjxAn80htba9zWKIsinQIcm+fF+6hUHy/ejtBOkYLD3pCfTa+jG
rZwQo5byDzBtgG4Epg+xnA4igRFU0xDXJv5Uz/CJuxPIRZ1f9iIO2f8TXLai6+nw
lJWwkjArcDfh+AlxlbrP3a4F6tcLZnFlt3kcirdAmFm/ahANXW2mjQM0TYv6o5gY
g/S9Etp6/VqY6tcrr21lTJBwHzs+7er10An0ndu8aXr8ejG1ar4XRGw3FzTneF4P
gvMzdu6S/xEVpNLiYgHWRk69fuH+J/9+T/HtIIBrkGhlqAQWsvu/2SUq3yy/MQfU
ixtipg2tfryizoHNCUxnuxSW3e+pfZ9TzYds7Gawo2NetirY3JNzOxUbXupnAuSR
YxIzJeFrLtoiyjHRUrMd
=OgYY
-----END PGP SIGNATURE-----
--CMLD6V24WUS0oql+--
討論串 (同標題文章)
完整討論串 (本文為第 2 之 12 篇)：