Hi all,
As mentioned in the PCP 3.8.0 release announcement, we now
have SASL2 integration in the PCP protocol and are looking
to build on that. The next stage is to provide a mechanism
for user access control in pmcd.
There is an existing pmcd mechanism for providing host-based
security as described in pmcd(1). Having started looking at
the way this works, combined with what we have learned SASL2
is going to provide us, it would appear that an extension to
the existing mechanism is very feasible and a fairly logical
next step. From pmcd(1), we logically have:
[access]
allow hostlist : operations ;
disallow hostlist : operations ;
So, for example:
[access]
allow clank.sgi.com : all, maximum 5 connections;
allow * : all except store, maximum 2 connections;
disallow smash, verge : store;
It would appear that we can extend this for users and groups,
in a backward-compatible way, with a syntax like:
[access]
allow users userlist : operations ;
disallow users userlist : operations ;
allow groups grouplist : operations ;
disallow groups grouplist : operations ;
allow hosts hostlist : operations ;
disallow hosts hostlist : operations ;
In the absence of any of host/user/group keyword, we fallback
to host (i.e. the current syntax).
So, this might give us an example pmcd.conf a bit like:
[access]
disallow user * : all;
allow user nathans : all;
disallow users bob, alice : store ;
allow group dev, ops : fetch, store ;
Not sure general user/group regular expressions make sense,
but a special-case wildcard of '*' for "any user" or "any
group" would be required I think.
>From an implementation point of view, this lets us make use
of alot of code that exists already for host access control.
I initially planned to find a way to allow access control to
be more fine-grained (per metric perhaps), but on reflection
I'm no longer convinced that the cost/benefit of adding that
to pmcd is favourable. Such fine-grained access is possible
- most of the access control code lives in libpcp, and as
such is also available to PMDAs. Thus, a PMDA with super-
secret-access-requirements can opt-in to doing any further
checking if it so chooses, while allowing us to keep the
pmcd code relatively simple.
So far, its looking like the event metrics are the most
likely metrics to need special handling in terms of access.
They also tend to have their own config files (thinking of
pmdalogger, for example) and their own ideas/mappings for
event-metrics/instances/parameter-metrics. So, I suspect it
is going to be impractical to solve all needs for these guys
in a generic way in pmcd, so deferring to the PMDA does feel
like a good option for finer-grained needs (with API help
via libpcp) - if they are ever needed.
Thoughts?
One other thing - I'm thinking that we will want to add
access controls to pmproxy as well (host-based too), and
possibly pmwebd as well - I'll look into abstracting bits
where possible from pmcd and adding to libpcp. Interested
PMDAs could make use of that as well if they wish.
cheers.
--
Nathan
|