> There are some access controls based on the IP address the client
> connects to PMCD on, but these are at the level of connection control
> (you can or cannot connect, you can or cannot store, you can or cannot
> fetch, etc).
This is too coarse with its management becoming intractable too quickly.
> Contexts are used to maintain a very small amount of state between the
> client and PMCD ... aside from IPC channel identification and the
> last sent profile, there is nothing else.
>
> And PMDAs can't see any of the client state when they recieve requests
> from PMCD.
The data gathering calls from our agent need to run in a user context.
Visibility/access of data
is dependent on the caller's uid. Our agent, if single threaded, would
need to setuid() to that of the data requester before each request.
We thought it better to hope that we could have a forking PMDA, which
would spawn off an agent per user, lasting as long as a context is
active, which seems to be the duration of a given TCP/IP connection. If
this were possible, then a connection to the user specific agent
invocation, might service requests from that user client, if such
navigation were possible.
If data fetching were the only possibility, then perhaps this might not
be a problem, but in our case
storing (or setting) metrics is subject to user privilege and thus needs
to be done in a specific user context too.
--
Peter J. MASON, Senior S/W Architect, Aurema Pty Ltd.
email: petem@xxxxxxxxxx
phone: +61-2-9698 2322
|