Hi, Nathan -
> Having used tunnels to access pcp, I can vouch for the level of pain for
> the end user ... option 2 is far, far better.
Very good.
> We should pay some attention to how this functionality would be enabled;
> I'm assuming it wouldn't be mandated for everyone. Some extension to
> the host specification might be the go - perhaps pcp://host:port and then
> pcps://host:port for a secure connection? [...]
We could reuse the tcp port, and initial insecure connection, and
by-default activate SSL when client & server mutually identify. But
perhaps forcing it on or off would be a worthwhile client / server
option pair. (For the server, maybe plop it into the pmcd.conf
[access] construct?)
> > [...] One bit
> > that's missing is the ability for local unprivileged users to offer up
> > their own PMDA processes for merging into the systemwide pmcd data
> > stream. Perhaps we just need another setuid-pmcd wrapper akin to
>
> Thinking about this some more since the meeting, and I'm wondering if
> this is really needed? ... I've never come across a need for this to date,
> have always been in the situation where the people doing system-level
> performance analysis have the ability to change how pmcd is configured
> (either directly or indirectly, via puppet or something along those lines).
I'm thinking about users doing user-level performance analysis though,
using the same tools as system-level peeps would. Such people may
want to monitor their private log files and processes, run their own
debugging or systemtap agents, that sort of stuff.
> The risk in allowing these unprivileged metric additions would be that we
> allow shared libraries and daemons to be executed on someone else's
> behalf, which might open a can of worms wrt how much that code can be
> trusted.
Oh definitely; per-unprivileged-user agents would have to be strictly
segregated from pmcd - no DSOs or execution of their code as root;
at most, communication across a pipe or unix-domain socket.
> OTOH, agents like pmdammv, which allows arbitrary user processes to
> extend the set of values on the fly might be a better model [...]
That's worthwhile too, but requires popularization of this particular
flavour of compiled-in instrumentation.
> > [acl]
> > forbid user : metric.name fetch, store;
> > forbid * : metric3.name list; (?)
> > allow *@host : metric2.name fetch;
>
> I can imagine some cases where a user should not be allowed to know
> whether a metric exists at all (i.e. namespace level permissions, a bit
> like directory permissions I suppose). So, may need a third permission
> mode (fetch, store, lookup)?
(Yes - that's what I was referring to as "list" above.)
> It would be kind of handy to keep all permissions information in the
> one place, now that I think about it, so perhaps this should not be
> visible to the agents after all.
The main exception would be where different domain-instance subsets
are to be visible to different clients. (My canonical example of this
is the /proc/$$/FOO metrics.) If so, at least the username could be
propagated to the PMDAs for doing additional, optional ACL
restricting.
> > Additionally, we could allow remote admins to upload acl bits, like
> > Mark's proposed scheme, or coarser "store pmcd.acl LINE" operations
> > or "store pmcd.acl.load_file FILENAME" operations.
>
> Not a big fan of either of those [...]
Yeah.
- FChE
|