The libcaps interprocess communication is now functional, though not implemented. Matt Dillon wrote how this could be worked up, which I am reporting wholesale:

” Speaking of CAPS, we now have all the major components
working: the client/server IPC model works, and the structural
encoding/decoding API works.

It should be possible to start working up replacements for
getpwnam() and all its friends. getpwent(), getpwuid(), getgrent(),
getgrnam(), getgrgid(), getserv*(), and so forth.

Basically the idea would be to have libc attempt to connect to the
appropriate IPC service to do such lookups. If the IPC service fails
libc would back-off to a direct uncached scan of the appropriate flat
file (ie.. so things still work well enough in single-user mode or when
the system is blown up that root doesn’t get locked out).

This involves:

* Creating services for password, group, services, and other directory
services (the resolver being the hardest). These services would:

– optionally run strictly on the flat file.
– optionally [re]generate and use DBM files from the flat files when
the flatfile is found to have been modified and an exclusive lock can
be obtained on it.
– optionally cache the flat files in memory instead of generating a DBM
file.
– process requests from clients and return results
– handle auxillary service interactions, such as YP lookups,
automatically.

* Rewiring libc.

– Remove direct YP and DBM support
– Connect to the appropriate service to perform a lookup
– Cache results locally so it does not have to perform an IPC for
every request (CAPS has or will have a mechanism whereby the
service will be able to notify clients of changes to have clients
invalidate their caches).
– Have an emergency fallback mechanism for when the CAPS service is
not available which does a simple uncached linear scan of the
associated flatfile.

* Starting and restarting services via RCNG. By default the services
would generate and maintain DBM files and fall-back to the in-memory
model if a DBM cannot be created. CAPS allows the namespace to be
overloaded, so it is possible to start a new copy of a service before
killing the old copy without interrupting any users of the service (well,
the libc code would have to detect the failure and reconnect, but the
reconnect would succeed because the new service would already be up and
running).

I think this would be quite a fun project. It certainly could be done
incrementally… for example, the services can be written, tested,
committed long before any libc work is done”