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