Do we want a server on `/servers/machine' (or similar)?

--===============1062574791==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="gatW/ieO32f1wygP"
Content-Disposition: inline


--gatW/ieO32f1wygP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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
=66rom 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

--gatW/ieO32f1wygP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFGQe6Wgfzh735dTTURApOJAJ40OwrVAzNGDiAhg6jNjp3QmkRbngCgh1/d
dZZB8+YjPyqPzdP9KRqVYT4=
=hFhh
-----END PGP SIGNATURE-----

--gatW/ieO32f1wygP--





--===============1062574791==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Hurd-devel-readers mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/hurd-devel-readers

--===============1062574791==--