Hello! The Hurd console needs to access i/o ports and video memory. Likewise does X.org. The pciutils need to access i/o ports.
For i/o ports we're fine, through the just-installed `i386_io_perm_create' and `i386_io_perm_create' rpcs (or through glibc's `ioperm', which in turn just uses those). The Hurd console's video memory access is also fine: for OSKit-Mach a `mmap' is done on `/dev/mem', for GNU Mach a `vm_map' is done after a `device_map' on the `kb' device; see `[Hurd]/console-client/vga-support.c'. However, for X.org video memory access is currently not possible, because I removed the `iopl' device from GNU Mach, which it previously used akin to the Hurd console using the `kb' device. Now, how about the following: we have a server sitting on `/servers/machine' (or somewhere else) that accepts rpcs like `io_perm_create' or `memory_map_create' and ``forwards'' (it need not really be forwarding) them to the kernel after having done some permission checking. That server would hold access to the device-master port (and host-priv as well?), so it could also -- being a proxy -- allow access to (e.g.) `i386_io_perm_create' to users that can't get such access by themselves, but can prove that they should be allowed such access. Proving this might be something like: ``When you're a member of the `console' group, you're allowed to get access to the i/o ports that deal with video output and to the video memory.'' An example: in order to get access to video i/o ports, user U invokes a `io_perm_create' rpc on the server S that is residing on `/servers/machine'. S checks and sees that U provided some capability to state that she's to be allowed such access. As a proxy, S invokes `i386_io_perm_create' on the device-master port and returns the resulting `io_perm_t' capability P to U. Then U can later directly invoke `i386_io_perm_modify' on P. What do you think? Is this a feasible approach? Regards, Thomas
signature.asc
Description: Digital signature
_______________________________________________ Bug-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-hurd
