Re: caps behaviour

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:I've started playing with caps a little and have some questions about
:how a few things behave. I've taken a look at the kernel-side source but
:not too in-depth yet.
:
:First, it seems like I can open several service ports with the same
:name. Is that correct? For example, in the case of a password lookup
:daemon, one could do:
:
:ucid = caps_sys_service(SERVICE_NAME, getuid(), getgid(), 0, CAPF_GROUP|CAPF_WORLD);
:rcid = caps_sys_service(SERVICE_NAME, getuid(), getgid(), 0, CAPF_USER);
:
:Then, you could have a thread waiting for messages on each port,
:responding with the crypted passwords on root's port but not doing
:the shadow lookups on the user port.
:
:Also, big thanks to Csaba Henk for the OpenGrok site, the code is much
:easier to chew in small bites, especially for folks not used to
:something as huge as the internals of the BSD source.

    For the caps_sys_service() system call uniqueness is determined by
    the combination of the name, uid, and gid.  CAPF_GROUP and CAPF_WORLD
    only applies to the caps_sys_client() system call.  Those flags do
    not apply to caps_sys_service().

    Duplicate registrations are allowed unless CAPF_EXCL is specified.  The
    idea here is two fold:

    * To be able to register a new daemon for a service before killing the
      old daemon.  There would be a short period of time where both demons
      would be able to accept requests (the kernel will route a new request
      to one of them), thus providing 'seemless operation' in the face
      of a switchover.

      Presumably the client(s) would also help implement this idea of 
      seemless operation by reconnecting when it gets an appropriate error
      code.

    * To be able to create localized services or backup services.  For
      example, the system standard service might run as root, but you
      could also run a version under your own user id which overrides
      the system standard service for programs run under your user id.

    Using your password lookup idea as an example, it wasn't really the
    intent to use the uid/gid distinction to separate crypted functionality
    from non-crypted functionality, though that can certainly be done and
    might even be beneficial from a security standpoint.

    Instead the idea is for e.g. the root server to support both crypted
    and non-crypted functionality by observing the creds that are passed
    to it along with a message.

    Local per-user services, distincted by the user id they are registered
    under, are primarily intended to allow a user to override system 
    standard services with his own local version, and also intended to
    allow IPC between cooperating users.

    The system calls do not handle automatica reconnection or automatic
    backoff (i.e. trying to connect to root if the user is not available).
    The idea is to have a library, e.g. libcaps, which provides API functions
    which do all that for the program.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>