Mark wrote:
> [...]
>> Any reason we couldn't/shouldn't use existing authentication frameworks?
>> For example, SASL. It supports username/password schemes, kerberos, etc.
>
> there's no technical reason we couldn't - e.g. libgsasl seems to be pretty
> portable (even has a mingw port). I just think the ssh key approach is
> the most simple, most portable and the easiest to manage.
In that case, one might imagine actual ssh being used. pmapi could
tunnel through ssh, as in git+ssh, as long as the remote side can
connect to the pmcd there and authenticate (a local unix pipe / uid+gid)?
>>> Access Control - Management
>>> Having the access control configuration accessible as PCP metrics
>>> will make it easy for authenticated admins to manage and query the
>>> current access control configuration and policies on a particular
>>> server, using existing PCP client tools.
>> ...
>>
>> I like this idea.
I see some attraction to it, but also consider a few issues.
What about persistency of the permissions? Each time pmcd starts up,
the permissions would have to be reloaded (via a shell script full of
pmstores), which is possibly a race condition.
What about metrics whose sensitivity is known to the PMDA, such as
/proc/$PID/cmdline (accessible only to the process $PID owner)? For
some of these, having the PMDA supply a template of pmstores to the
startup script could be enough, but others are too dynamic.
What about groups? They'd be useful here for the same reason groups
as in unix in general.
What about domain-instances? Some metrics may need per-domain-inst
privileges.
- FChE
|