[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Do we want a server on `/servers/machine' (or similar)?
From: |
Thomas Schwinge |
Subject: |
Do we want a server on `/servers/machine' (or similar)? |
Date: |
Wed, 9 May 2007 17:53:58 +0200 |
User-agent: |
Mutt/1.5.11 |
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
- Do we want a server on `/servers/machine' (or similar)?,
Thomas Schwinge <=