On 05/18/2011 03:34 AM, Frank Ch. Eigler wrote:
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,
hmm, certainly sounds like the least painful way to get almost
everything we want out of the transport/connection parts of this
proposal - secure authenticated connection with encryption over
the wire. And with minimal new dependencies.
as long as the remote side can
connect to the pmcd there and authenticate (a local unix pipe / uid+gid)?
One possible nit - I need to monitor a machine that I don't have an
a login account on. So "pcp+ssh" would connect my client to pmcd on
the server over an ssh tunnel (client <-> sshd <-> pmcd). But then,
once connected, we'd still need to do PCP authentication of some sort
so pmcd trusts my identity for authorization purposes - this would
still need an authorized_keys file associated with pmcd, and a
PCP protocol extension for the pmNewContext() handshake, right?
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.
pmcd (or maybe the pmcd PMDA) could just read this directly from a
local database on startup (before accepting any connections). The
pmstore idea was for ease of remote administration - an authenticated
admin would have 'store' privileges to pmcd.control.security; the
store handler for that metric (in the pmcd PMDA) would write to
and maintain the local permissions database (and presumably manage
the PCP authorized keys).
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.
that's a pretty weird case - there's no way I can think of to associate
the owner of a process on the server with an authenticated remote client.
PIDs are too dynamic for this to make sense I think.
What about groups? They'd be useful here for the same reason groups
as in unix in general.
yes I agree, but then we'd have to maintain a group database and
provide administration facilities for that too. Perhaps this kind
of thing could be accomplished by sharing keys on the client side.
What about domain-instances? Some metrics may need per-domain-inst
privileges.
conceivably, ... but my head hurts :P
Cheers
-- Mark
|