Messages in this thread |  | | Date | Sat, 2 Sep 2000 09:06:34 -0600 | From | Richard Gooch <> | Subject | Re: [PATCH] mtrr: s/suser/capable/ |
| |
Jamie Lokier writes: > Richard Gooch wrote: > > I agree. Firstly, you can't frob random memory with the MTRR driver, > > so it clearly doesn't need CAP_SYS_RAWIO. > > With it you can change the behaviour of other drivers by changing > the properties of their MMIO space. So it should need > CAP_SYS_RAWIO, IMHO.
In theory, you could get another driver to crap over random memory. In practice, you're more likely to get the other driver to lockup :-)
Since the major user of the MTRR driver is X, which needs CAP_SYS_RAWIO anyway, I guess it's not unreasonably limiting to require it, if people really want to push this.
However, the check should be in the open() method, when someone asks for write access. Then the suser() checks should be changed to checks for write access instead. This will allow FD passing, which I think is a good thing. Imagine some kind of hardware access daemon which authenticates write access to the MTRRs and then passes a FD. That way, clients which only want write access to the MTRRs don't need to be given CAP_SYS_RAWIO. They'd have a lesser privilege (via some user-space authentication mechanism) instead.
Regards,
Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |