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_S
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.
-- Jamie
-
To unsu
Chris Evans writes:
>
> On Thu, 31 Aug 2000, Tigran Aivazian wrote:
>
> > Actually, microcode driver checks CAP_SYS_RAWIO only on open() so it would
> > allow access to the receiver of fd even he has no CAP_SYS_RAWIO
> > privilege. Hmmm, maybe I should put it back into write() method, as Linus
>
> speaking of /dev/kmem, I always wondered why Alan Cox (or someone
> else?) objected to adding vwrite() ability to write to vmalloc'd addresses
> via /dev/kmem and this discussion is as good as any to ask here :)
If it can be done cleanly without races fore 2.4 then I dont see a problem.
I also
On Thu, 31 Aug 2000, Chris Evans wrote:
> I'm not sure about /proc/kcore (it looks to be read only),
even reading from certaing ioremap'd areas is dangerous. (ok current
/proc/kcore prevents that from happening by skipping such).
> but /dev/mem
> and /dev/kmem are good examples.
speaking of /d
> > RAWIO is about hardware level access not Stephens O_DIRECT stuff
>
> So why is /proc/kcore access SYS_RAWIO then ?
You can tamper with arbitary memory via it in theory
> And why is nvram access not SYS_RAWIO ?
You cant make the nvram tamper with arbitary memory
-
To unsubscribe from thi
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 overl
On Thu, 31 Aug 2000, Andi Kleen wrote:
> > > And why is nvram access not SYS_RAWIO ?
> >
> > You cant make the nvram tamper with arbitary memory
>
> But it is clearly hardware access isn't it ?
So is /dev/fd0. And you can set a lot of interesting
ioctl()s with a handle to that and CAP_SYS_AD
On Thu, Aug 31, 2000 at 01:05:15PM +0100, Alan Cox wrote:
> > And why is nvram access not SYS_RAWIO ?
>
> You cant make the nvram tamper with arbitary memory
But it is clearly hardware access isn't it ?
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
On Thu, 31 Aug 2000, Tigran Aivazian wrote:
> Actually, microcode driver checks CAP_SYS_RAWIO only on open() so it would
> allow access to the receiver of fd even he has no CAP_SYS_RAWIO
> privilege. Hmmm, maybe I should put it back into write() method, as Linus
> (or someone else) did at some p
On Thu, 31 Aug 2000, Andi Kleen wrote:
> On Thu, Aug 31, 2000 at 12:11:31PM +0100, Alan Cox wrote:
> > > > These cases in mtrr.c are clearly CAP_SYS_RAWIO.
> > >
> > > Clearly? How do MTRR changes relate to rawio ?
> >
> > RAWIO is about hardware level access not Stephens O_DIRECT stuff
>
> S
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 memor
> > These cases in mtrr.c are clearly CAP_SYS_RAWIO.
>
> Clearly? How do MTRR changes relate to rawio ?
RAWIO is about hardware level access not Stephens O_DIRECT stuff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Plea
On Thu, Aug 31, 2000 at 12:11:31PM +0100, Alan Cox wrote:
> > > These cases in mtrr.c are clearly CAP_SYS_RAWIO.
> >
> > 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 ?
And why i
On Thu, Aug 31, 2000 at 11:27:17AM +0100, Matthew Kirkwood wrote:
> > - if ( !suser () ) return -EPERM;
> > + if ( !capable(CAP_SYS_ADMIN) ) return -EPERM;
>
> Please think further about these random changes. CAP_SYS_ADMIN
> is already bloated with useless junk and these aren't helping
> the
On Thu, 31 Aug 2000, Matthew Kirkwood wrote:
> On Thu, 31 Aug 2000, Tigran Aivazian wrote:
>
> > Actually, microcode driver checks CAP_SYS_RAWIO only on open() so it
> > would allow access to the receiver of fd even he has no CAP_SYS_RAWIO
> > privilege. Hmmm, maybe I should put it back into wri
On Thu, 31 Aug 2000, Tigran Aivazian wrote:
> Actually, microcode driver checks CAP_SYS_RAWIO only on open() so it
> would allow access to the receiver of fd even he has no CAP_SYS_RAWIO
> privilege. Hmmm, maybe I should put it back into write() method, as
> Linus (or someone else) did at some po
On Wed, 30 Aug 2000, Arnaldo Carvalho de Melo wrote:
> Please consider applying.
And then please don't apply.
>case MTRRIOC_ADD_ENTRY:
> - if ( !suser () ) return -EPERM;
> + if ( !capable(CAP_SYS_ADMIN) ) return -EPERM;
Please think further about these random cha
On Wed, 30 Aug 2000, Arnaldo Carvalho de Melo wrote:
> -if ( !suser () ) return -EPERM;
> +if ( !capable(CAP_SYS_ADMIN) ) return -EPERM;
no, it should be CAP_SYS_RAWIO. I thought that is the convention for
accessing chipset-specific io features. E.g. see
arch/i386/kernel/microcode.c.
Reg
On Wed, 30 Aug 2000, Richard Gooch wrote:
> Grumble. Someone tell me why we can't just remove the suser() calls
> entirely and instead test if the file has write access? That's what
> the permissions on the file are for. Read access lets people take a
> look, but write access is required to change
Arnaldo Carvalho de Melo writes:
> Em Wed, Aug 30, 2000 at 10:49:22PM -0400, Richard Gooch escreveu:
> > Tigran Aivazian writes:
> > > On Sat, 26 Aug 2000, Arnaldo Carvalho de Melo wrote:
> > > > - if ((current->tty != tty) && !suser())
> > > > + if ((current->tty != tty) && !capable(C
Em Wed, Aug 30, 2000 at 10:49:22PM -0400, Richard Gooch escreveu:
> Arnaldo Carvalho de Melo writes:
> > Hi,
> >
> > Please consider applying.
> >
> > - Arnaldo
> >
> > --- linux-2.4.0-test8-pre1/arch/i386/kernel/mtrr.c Thu Jul 13 01:58:41 2000
> > +++ linux
Arnaldo Carvalho de Melo writes:
> Hi,
>
> Please consider applying.
>
> - Arnaldo
>
> --- linux-2.4.0-test8-pre1/arch/i386/kernel/mtrr.cThu Jul 13 01:58:41 2000
> +++ linux-2.4.0-test8-pre1.acme/arch/i386/kernel/mtrr.c Wed Aug 30 20:52:48
>2000
Hi,
Please consider applying.
- Arnaldo
--- linux-2.4.0-test8-pre1/arch/i386/kernel/mtrr.c Thu Jul 13 01:58:41 2000
+++ linux-2.4.0-test8-pre1.acme/arch/i386/kernel/mtrr.c Wed Aug 30 20:52:48 2000
@@ -1427,7 +1427,7 @@
char *ptr;
char line[
24 matches
Mail list logo
