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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:13 EST