----- Original Message -----
>
> nathans wrote:
>
> > [...]
> > Introduces knowledge of each connection, and its security attrs
> > (particularly uid and gid), in pmdaproc. This allows a suitably
> > configured pmcd process (with user/group ACLs) and authenticated
> > client connections to be able to retrieve sensitive information
> > for the specific authenticated user and not others. Without ACL
> > specification in pmcd.conf the behaviour is unchanged from today
> > (i.e. pmdaproc always runs as root and can access everything).
>
> How would this ACL look in practice?
These ACLs are as described here...
http://oss.sgi.com/pipermail/pcp/2013-May/003483.html
> ... We certainly wouldn't want to
> require a sysadmin to enumerate all userids in an ACL, just to have
> pmdaproc be willing to setuid-or-equivalent-check for them for proc
> file reading.
Yep, agreed, that definitely won't work.
> Perhaps we need only an option for pmdaproc that says
> "show-own-processes-only": ie., for authenticated pcp connections, use
> the given uid for permission checks; for unauthenticated pcp
> connections, show nothing. This would allow us to enable pmdaproc by
> default. (Having a pmcd.conf level ACL can compose with this to
> impose further restrictions.)
I think the desired outcomes can be achieved in pmcd without adding in
new pmdaproc options (but I might be wrong there - its still early days).
The current pmdaproc behaviour is dependent on how pmcd.conf is setup:
- no user/group ACLs in [access] section
Historical behaviour remains unchanged - everyone can access all process
metrics. "everyone" in this context means both local and remote users.
If someone chooses to authenticate, then some instances of some metrics
may not be available to them (this is slightly wierd, but not much we
can do about this AFAICT, and unlikely to be a problem in practice).
- user/group ACLs in [access] section (including a wildcard entry)
This will mean: no authentication, no access (to anything, not just proc).
While this might seem draconian, the defaulting-to-authenticated AF_UNIX
sockets (no username/password interaction) along with the possibility of
getting SASL to allow password-less login will mean that we can become
secure-by-default with no loss of functionality. I think. I haven't yet
got a working no-password SASL connection for non-anonymous users, but I
think thats more a coding issue on my part, not a fundamental limitation.
It is highly likely that we will move toward having at least a "pcp" user
entry in the [access] section by default down the track (and that implies
a requirement for authentication for everyone).
Anyway, back to pmdaproc - once all connections are authenticated, things
hopefully make more sense. In particular your point about "unauthenticated
pcp connections, show nothing" resolves itself in a backward-compatible way
without the need for running pmdaproc in a special mode... (I hope!) Quite
possible I've overlooked something, only just really starting to think
through and observe the ramifications of all the authentication stuff. :)
cheers.
--
Nathan
|