Red Hat Bugzilla – Bug 1295551
some pipe pmda issues
Last modified: 2016-07-19 14:38:37 EDT
In pcp-3.10.9-1.fc22.x86_64: - the pipe pmda is in the core pcp rpm instead of a subrpm - it does not include an empty /etc/pcp/pipe.conf.d directory, without which the pmda startup fails - it should probably include at least a blank pipe.conf file (owned by root!) so the pmda will at least start (for testing purposes) - it excludes the pmdapipe man page - the pmdapipe page does not explain what happens security-wise if there is no [access] clause - the pmdapipe page does not explain invocation-parameter quoting rules, such as for passing metacharacters or embedded spaces - 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 [access]-less default appears to be to GRANT access - installing said sample.conf as pipe.conf, restarting pmcd, then running # 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. # pmval -Dall -i bdev_trace -x '50 /dev/md0' pipe.firehose results in a SEGV; valgrind has multiple complaints - cursory code review shows numerous unchecked strdup() calls; consider at least assert()ing those against OOM
# pmval -i rw_syscalls -x $$ pipe.firehose results in no output, but a spinning perf-script process left around in the background
(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.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.