[lkml]   [2000]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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

    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:38    [W:0.020 / U:189.576 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site