On Wed, Oct 03, 2001 at 04:53:51PM -0400, Roland McGrath wrote:
> First, as to the kernel implementation issue. Adding a new IKOT_* flavor
> is not really hard, and having extra flavors for machine-specific features
> is fine by me. But I was also thinking it might just be easiest to stick
> with device_t anyway, since it has the IPC setup all dealt with already
> (and the various new bits of IKOT_* and intran/outtran magic would just
> duplicate what's there for device_t).
This sounds reasonable. It would be a dummy device with only side effects.
However, if possible, I think it makes sense to give the RPC arguments a
name different from device_t, to avoid confusion.
> Your scheme #2 makes ioperm much easier. A root ioperm caller
> could just get a capability for all ports, and then make a call saying what
> change to make to the task.
Sounds good to me.
> I don't think extracting io port capability from the task is a good thing.
> If there are RPCs for subsetting (or unioning) that can be done, they
> should be sent to the io port capability port itself (like Hurd auth handles).
The reason I included that is to make it possible for a security concerned
task to drop the permission, even if it doesn't have the privilege to create
a new object representing it. I now see in Linux that they appear to allow
this (i386/kernel/ioport.c):
if (turn_on && !capable(CAP_SYS_RAWIO))
return -EPERM;
So if you just want to turn it off, you don't need permission. However,
this is certainly a rare case, and we might not want to bother about it at
all now.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
