Matthew Kirkwood writes:
> On Tue, 15 Feb 2000, Tigran Aivazian wrote:
>
> > Is there any reason why does mtrr (e.g. mtrr_ioctl()) use the old
> > suser() instead of the new capable() (e.g. CAP_SYS_ADMIN seems the
> > closest) to do permission check?
>
> I don't know about the reason, but I would prefer CAP_SYS_RAWIO, if
> it's messing with hardware settings.
Maybe because capabilities weren't around (I can't remember) when the
MTRR code was written? And no-one has considered it important enough
to subsequently change?
Frankly, before you start messing with replacing suser(), I'd rather
that we hammer out the exact meaning of capability bits, and what the
"range" of each bit is. The very fact that there are two separate
suggestions for which bit to use for MTRR bothers me: the decision
should be obvious from the documentation on capabilities. It leaves me
less than lukewarm about capabilities.
So I'd rather that MTRR was left alone until the house of capabilities
is cleaned up.
Regards,
Richard....
Old: 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.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:30 EST