Currently, when emerging app-admin/collectd[+filecaps], the following capabilities are set: CAP_SETGID, CAP_SETUID, CAP_NET_ADMIN, CAP_NET_RAW. There is at least one plugin however (the 'smart' plugin) which requires CAP_SYSRAWIO to function correctly when collectd isn't run as root, and only certain plugins need CAP_NET_ADMIN or CAP_NET_RAW. I can understand not having CAP_SYS_RAWIO set by default, since the 'smart' plugin isn't built by default, and that particular capability is potentially very dangerous, but the same logic could be used for CAP_NET_RAW, which is set by default but as far as I can tell isn't needed by any of the plgins which are built by default. Given this, it would be nice if the filecaps USE flag resulted in the capabilities that are actually needed for the built plugins being set, instead of just having a static set defined. Additionally to that, it might be good to have a message printed out by the ebuild showing which capabilities were set and by which plugins. Bug #600392 is probably related to this (the reported issue is consistent with how collectd behaves when run as a non-root user without CAP_SYS_RAWIO when trying to use the 'smart' plugin).
OK, just realized that the ebuild already does this, but doesn't do it for collectd_plugins_smart. I'll have a patch to add that one some time later today.
Created attachment 467224 [details, diff] Patch for ebuild to add check for collectd_plugins_smart OK, so I hadn't realized the ebuild already does this (apologies for the noise), it just doesn't make the check for the smart plugin. Here's a patch to update it to do so.
*** Bug 600392 has been marked as a duplicate of this bug. ***
We already set capabilities based on chosen plugins, see https://gitweb.gentoo.org/repo/gentoo.git/tree/app-admin/collectd/collectd-5.6.2.ebuild#n469 We are just missing an entry for smart plugin. Are you sure that "CAP_SYS_RAWIO" is enough? Can't test by myself because I currently don't have access to a system supported by libatasmart.
(In reply to Thomas Deutschmann from comment #4) > We already set capabilities based on chosen plugins, see > https://gitweb.gentoo.org/repo/gentoo.git/tree/app-admin/collectd/collectd-5. > 6.2.ebuild#n469 > > We are just missing an entry for smart plugin. > > Are you sure that "CAP_SYS_RAWIO" is enough? Can't test by myself because I > currently don't have access to a system supported by libatasmart. I know it doesn't need any other capabilities. It may need ACL's set on the disk too, but I'm not 100% certain. I can double check that later today and get back with you.
OK, further update, the smart plugin needs CAP_SYS_RAWIO and the user running collectd has to have read access to the disks to be monitored. The following udev rule will cover this on Gentoo for most systems with the default user, assuming the system has sys-apps/acl installed: KERNEL=="sd?", SUBSYSTEM=="block", ACTION=="add", RUN(program)+="/bin/setfacl -m 'u:collectd:r' %E{DEVNAME}" That rule will fall flat on it's face on systems using the kernel's (deprecated and obsolete) IDE subsystem instead of libata, using certain HBA's which need special stuff done to apss through SMART commands, or with more than 26 ATA/SCSI/USB block storage devices connected to the system. It may also result in slightly wider permissions than needed (collectd will be able to access all /dev/sdX devices, not just the ones it's monitoring). Overall, I think the best option is to add the capability, and then add a message like the following if collectd_plugins_smart is enabled: 'The SMART plugin for collectd requires read access to the disk devices you tell it to monitor. The recommended way to achieve this is to install sys-app/acl and write a udev rule to add an ACL to the disks so that collectd has read access.'
Now in repository, https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=179965f9f272332d4aebd8193a112a51004a10bc Thanks for the report!
