Re: Do we want a server on `/servers/machine' (or similar)?
Thomas Bushnell BSG <[email protected]> Wed, 09 May 2007 09:54:22 -0700
| Newsgroups | gmane.os.hurd.devel.readers |
|---|---|
| Message-ID | <1178729662.24657.14.camel__25391.7845817798$1178729770$gmane$org@localhost> |
--===============2009571466== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-PTZi0izmz+1tmIfZp5RU" --=-PTZi0izmz+1tmIfZp5RU Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2007-05-09 at 17:53 +0200, Thomas Schwinge wrote: > 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.'' I think this is roughly the right structure, sounds good. I don't much like the name /servers/machine; so let's figure out something better. Names like that persist forever, so it's actually more important than it might seem to get them right from the get-go. Thomas --=-PTZi0izmz+1tmIfZp5RU Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGQfy+qMsB9b6fcOoRAjxvAKDI9FXvFOj5GlZo6t+UVdgoFHQ9SgCdE9Gy MtyQwcEZqkwe1An1BkXHYqM= =pb8+ -----END PGP SIGNATURE----- --=-PTZi0izmz+1tmIfZp5RU-- --===============2009571466== 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 --===============2009571466==--