Re: [PATCH] mtrr: s/suser/capable/

• Next message: Alan Cox: "Re: [PATCH] mtrr: s/suser/capable/"
• Previous message: Matthew Kirkwood: "Re: [PATCH] mtrr: s/suser/capable/"
• In reply to: Matthew Kirkwood: "Re: [PATCH] mtrr: s/suser/capable/"
• Next in thread: Tigran Aivazian: "Re: [PATCH] mtrr: s/suser/capable/"
• Reply: Tigran Aivazian: "Re: [PATCH] mtrr: s/suser/capable/"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Thu, 31 Aug 2000, Matthew Kirkwood wrote:

> On Thu, 31 Aug 2000, Andi Kleen wrote:
>
> > > > Clearly? How do MTRR changes relate to rawio ?
> > >
> > > RAWIO is about hardware level access not Stephens O_DIRECT stuff
> >
> > So why is /proc/kcore access SYS_RAWIO then ?
>
> I kind of overloaded CAP_SYS_RAWIO to restrict access to bits
> of arbitrary memory. Maybe this one should require CAP_PTRACE
> and CAP_DAC_OVERRIDE instead.

Anything which could provide raw access to kernel memory needs
CAP_SYS_RAWIO, so that both this capability (along with
CAP_SYS_MODULE) can be revoked to useful effect.

I'm not sure about /proc/kcore (it looks to be read only), but /dev/mem
and /dev/kmem are good examples.

Cheers
Chris

-
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/

• Next message: Alan Cox: "Re: [PATCH] mtrr: s/suser/capable/"
• Previous message: Matthew Kirkwood: "Re: [PATCH] mtrr: s/suser/capable/"
• In reply to: Matthew Kirkwood: "Re: [PATCH] mtrr: s/suser/capable/"
• Next in thread: Tigran Aivazian: "Re: [PATCH] mtrr: s/suser/capable/"
• Reply: Tigran Aivazian: "Re: [PATCH] mtrr: s/suser/capable/"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:27 EST