The finding at the tail end of
http://oss.sgi.com/pipermail/pcp/2014-November/006062.html
is reproduced thusly on 3.9.10, on a 2.6.18-398.el5 kernel.
(3.9.10 happens to be freshest on epel-testing.)
(# - run as root; % - run as unprivileged user)
# sudo service pmcd restart
% cat /proc/1/maps
cat: /proc/1/maps: Permission denied
% pmval -s 1 -i 1 proc.memory.maps
[...]
1
""
[i.e., value not available ... though no error, hm]
# service pmcd restart
# pmval -s 1 -i 1 proc.memory.maps
[...shows results, as expected...]
% pmval -s 1 -i 1 proc.memory.maps
[...shows results, as unexpected!...]
In this case, unlike for bug #1101, the kernel does report
a read error (EACCES) for the proc/1/maps file descriptor,
so the new client is not permitted to get new data. But...
The pmda (due to its "refresh" caches?) goes on to supply
stale and confidential data to the unprivileged pcp client.