DragonFly BSD
DragonFly kernel List (threaded) for 2003-11
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Bind update

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sun, 23 Nov 2003 11:25:47 -0800 (PST)

:For those who aren't clear what rendezvous is could someone provide a 
:link and/or explanation?

    Sure thing.  Basically the API looks like this:

    lwkt_port_t caps_service(const char *name, gid_t gid, mode_t modes, int flags)

	Create a named service port.  The port is created under your current
	uid.  The gid of the port will be set to the specified gid (-1 for
	default) and the specified modes will be used.  Other processes will
	be able to connect to your port based on the permissions you have

    lwkt_port_t caps_client(const char *name, uid_t uid, int flags)

	Connect to a service por created by another process.  If uid is -1
	first attempt to connect to a service port created by the current uid,
	and if that fails try to connect to a service port (originally)
	created by root.

    That's it!  Well, ok, not quite it... the idea is that once you have the
    ports in hand you can use standard LWKT messages (in userland) to have
    a client send a request to a server and the server to reply to the

    The guts of the code is a lot more complex.  The userland library obviously
    has to set the mp_* function vectors for the returned port to deal with
    the messaging and the userland library will use UNIX domain sockets
    internally to pass data between client and server.  In fact, to make
    my job easier I am restricting the userland to non-threaded (blocking)
    operation just so I can get the thing written.  This is a security issue,
    of course (blocking operations, that is), but its good enough to start
    developing interfaces for authentication, DNS lookups, and so forth.

    Once the operations are moved into the kernel there will be no such
    restrictions and I'll be able to implement magic server-side forking
    to isolate services on a per-uid basis, so for example user X trying to
    crash the service will not effect user Y trying to use the service.

    Galen, this library will also include a user-compiled version of
    the LWKT messaging and threading modules which you and I can then
    work on to get userland threading working.  My initial commit will not
    get userland LWKT threading working, it will just get enough of the
    infrastructure in place such that userland can use the LWKT messaging

					Matthew Dillon 

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]