Hi, Nathan -
nathans wrote:
> My colleague Will Cohen recently floated the idea of using PCP to
> carefully lift some permissions restrictions in tools like perf,
> and to enable perf functionality to be injected into PCP to some
> extent. [...]
It seems to me that the perf angle to this is peripheral; the
hypothetical new pcp capability is on-demand remote invocation of
console programs and collection of their outputs.
> [...] We could tackle this problem with a new pmdapipe(1) agent in
> PCP
(Just toolshedding, but I'd suggest "pmdaexec" or similar instead of
"pipe", which reflects an internal implementation artifact.)
> running as root and arbitrating access to the privileged commands.
We will need to be absolutely paranoid with this, especially if we're
thinking of running commands as root. Even just information
disclosure can be a problem, for mundane-sounding things like
kernel-tracepoint traces. Letting less-than-root-credentialed clients
access such information is also contrary to our traditional security
philosophy; we've never tried to be a deliberate privilege-escalator.
> This PMDA would primarily export one event metric, with records of
> string type holding the command output.
(Or one metric per configured command.)
> One of a configured set of commands could be executed via pmevent(1)
> connecting to this PMDA (via pmcd) which would execute the requested
> command [...]
Sounds good.
> The piping (hot) PMDA would be more involved. It would need to:
> - enforce access controls [...]
Right!
> - provide a mechanism for configuration of a set of allowed commands
> that it is prepared to execute, and a way to map the parameters to
> the command line before executing the tool.
This part will be tricky to have a good tradeoff point between
generality & safety. For example, we'll need super careful
e.g.-wordexp(3) quoting of the parameters.
> - track each remote client using the client-context-tracking [...]
> - once user credentials and parameters have been passed, and tracing
> begins (via client-driven fetch), fork/exec the relevant command [...]
> - either when the child command exits or the client tool disconnects, [...]
Yup and yup and yup. Also worth considering is an option to collect a
fixed quantity of output, whether measured in screenfuls, lines, or
time. Also worth considering is an option to control child command
output buffering - line-by-line vs. arbitrary-buffer vs. time-based
as it's passed onto the event buffers.
> To achieve the generalised configuration goals (while restricting the
> runnable commands to a sanitised, secure, sysadmin-approved set), the
> PMDA could read a configuration file on startup (and SIGHUP), perhaps
> with a syntax along these lines:
>
> $ cat /var/lib/pcp/pmdas/pipe/sample.conf
> # instance user commands
> rw_syscalls root perf script rw-by-file $1
> bdev_trace root btrace -w $1 /dev/$2
(I wouldn't be surprised if a "run-as-same-user" type invocation
option would make an appearance here.)
> [access]
> allow user bob : all;
> allow group perf : rw_syscalls;
> [...]
> $ pmevent -i bdev_trace -x '5 sda' pipe.firehose
> 8,2 5 1 0.000000000 25227 A WS 734332384 + 24 <- (253,2) 734330336
> 8,0 5 2 0.000000414 25227 A WS 735358432 + 24 <- (8,2) 734332384
> 8,0 5 3 0.000000756 25227 Q WS 735358432 + 24 [qemu-kvm]
> [...5 seconds worth]
> $
A nice example.
Consider also system overview type commands, which could be quite
informative if logged periodically, along with some crazier ideas:
"ps -ef"
"kill $1"
"smartctl -a $1"
"dmidecode"
"top -n 1" # <-- may need a pty, not just a plain pipe!
"find /sys/devices/system/edac | xargs grep ."
"dbus-monitor"
"cat $1"
"iptables -v -l -t $1"
"servicectl"
"service $1 $2"
- FChE
|