https://bugzilla.redhat.com/show_bug.cgi?id=1295551
--- Comment #2 from Nathan Scott <nathans@xxxxxxxxxx> ---
(In reply to Frank Ch. Eigler from comment #0)
> In pcp-3.10.9-1.fc22.x86_64:
>
Thanks for trying it out.
> - the pipe pmda is in the core pcp rpm instead of a subrpm
Thats by design. There are a number of small, core PMDAs with no external
dependencies in the core pcp package, and I felt this was useful enough that it
should be with those.
> - it does not include an empty /etc/pcp/pipe.conf.d directory, without which
> the pmda startup fails
$ rpm -qf /etc/pcp/pipe.conf.d
pcp-3.11.0-1.x86_64
> - it should probably include at least a blank pipe.conf file (owned by
> root!) so the pmda will at least start
A blank pipe.conf buys nothing (pmdapipe will still not start). I'm not really
convinced we should have a default - I couldn't come up with anything that
would be OK to run as root without someone explicitly asking for that (perhaps
exit(0)? but again, not useful).
> (for testing purposes)
See qa/878.
> - it excludes the pmdapipe man page
Its in pcp-doc with everything else.
> - the pmdapipe page does not explain what happens security-wise if there is
> no [access] clause
*nod*
> - the pmdapipe page does not explain invocation-parameter quoting rules,
> such as for passing metacharacters or embedded spaces
*nod* - shell metacharacters and embedded spaces are not permitted in the
config by design (its not run via sh(1)) - should make a note.
> - the sample.conf should have an [access] block that makes it less likely
> that someone installing the sample.conf as pipe.conf will thereby give
> random local users access to the running-as-root programs therein, since the
Right. These are the sorts of reasons why I didn't install a default config on
the users behalf - I think people should always opt-in.
> [access]-less default appears to be to GRANT access
*nod*
> - installing said sample.conf as pipe.conf, restarting pmcd, then running
>
Is qa/878 passing on this machine? I'll dig deeper into some of these other
issues shorty, thanks.
> # pmval -i bdev_trace pipe.firehose
> results in no output; no errors; no log entries; as per strace no attempt to
> run the btrace binary; some pmda -Dall suggests internal error -12391 at
> some point; because of bug #1229494, one can't strace -Dall effectively
>
> # pmval -i bdev_trace -x "5 BADDEVICE" pipe.firehose
> results in no output, even though btrace must have signalled a failure on
> its stderr; similarly no log/output if the /usr/bin/btrace program is not
> installed at all
>
> # pmval -i bdev_trace -x "5 DEVICE" pipe.firehose
> results in output; the [end] flag is set on many of the last lines, so they
> don't match up with the single [start]-flagged line at the top;
> event-flagging behaviour should be documented in man page
>
> # pmval -i bdev_trace -x "5 DEVICE JUNK JUNK JUNK" pipe.firehose
> quietly ignores JUNK; if this is desirable, it should be documented
>
> # pmval -i rw_syscalls -x /dev/null pipe.firehose
> results in pmval: store value "/dev/null" failed: Bad input to pmstore
> which would be OK if it were to signal that "perf script rw-by-file" errors
> out on that input, but that's probably not what it means.
The above look like access control and config documentation issues at first
glance FWLIW.
> # pmval -Dall -i bdev_trace -x '50 /dev/md0' pipe.firehose
> results in a SEGV; valgrind has multiple complaints
Can you post all those details please? Taa.
> - cursory code review shows numerous unchecked strdup() calls; consider at
> least assert()ing those against OOM
IIRC, those are in places where subsequent checks will error out later on, but
will double check.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/token.cgi?t=XOsKanBnDw&a=cc_unsubscribe
|