Starting with 1:5.33.0-2, the monit systemd unit file got some hardening. Beside other things,
the CapabilityBoundingSet got restricted to: CAP_DAC_READ_SEARCH CAP_NET_RAW CAP_SYS_PTRACE

I'm executing a "check program" script which checks the state of some wireguard tunnels. After
upgrading monit, these checks ceased to work and returned a 'permission denied' error.

The issue was traced back to the strict CapabilityBoundingSet. Assigning the `CAP_NET_ADMIN`
capability to monit resolved the issue. This change was applied via a systemd override:

| # in etc/systemd/system/monit.service.d/override.conf
| [Service]
| CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_NET_RAW CAP_SYS_PTRACE CAP_NET_ADMIN

Debugging this issue was challenging. It seems the new hardening measures could be
too restrictive for certain use cases. I suggest reconsidering the default
CapabilityBoundingSet settings, or perhaps implementing a more granular system
where permissions can be adjusted based on different aspects of the service
(e.g., less permissions for the monit API and outgoing HTTP calls, and more
permissions for "program check").

This problem can be reproduced by this check:

| check program link_wg0_home path "/usr/bin/wg show wg0"
| 	if status != 0
| 	    for 2 cycles
| 	    then alert

Thank you!

As monit is a configurable system monitoring tool, it is expected that
admins will expand it to monitor all aspects of a system. The configured
system hardening rules block what seem like common use cases.  Two
additional ones are:

1. To run systemctl on an NVMe drive needs CAP_SYS_ADMIN and on a SATA
drive needs CAP_SYS_RAWIO
2. Monit is commonly used to restart other services (usually with
systemctl) so it should have all the capability to run whatever is required
in other service files.

See https://bitbucket.org/tildeslash/monit/issues/1109/unable-to-monitor-
php-fpm-unixsockets-on in which CAP_DAC_OVERRIDE is required to monitor,
restart php-fpm.

Instead of playing whack-a-mole on permissions as admins try to use monit
as intended, it might be better to not be as restrictive.
Thanks

Jeff

This is a matter of inadequate documentation.
Nor man page monit(1) neither additional doc files write about capabilities or systemd.

Yes, I had to play whack-a-mole for two months until I discovered
why does not uid/gid setting work.

BR

Gabor