Details
-
Bug
-
Status: Resolved (View Workflow)
-
Medium
-
Resolution: Fixed
-
29.0.6
-
Security Level: Default (Default Security Scheme)
-
5
-
Horizon 22 - March 16 - 30, Horizon 22 - March 30 - Apr 13
-
Backlog
Description
Minion's systemd unit is sets User=root and executes /etc/init.d/minion start, which does runuser -u $RUNAS to drop privs to $RUNAS
If capabilities (using AmbientCapabilities) are added to the systemd unit via systemctl edit opennms, such as required to bind Minion to privileged ports, these capabilities are lost when runuser forks as capabilities are not inheritable.
This forces the user to use fs-based capabilities set on the Java binary, which are more difficult to maintain and frequently "lost" when Java is upgraded or the path to Java changes, or to revert to running the Minion as root. Both of these workarounds grant more permissions than required. This also forces an inconsistency in how we recommend customers manage capabilities on core versus on minion.
This can be worked around by by setting User=minion in the systemd unit and setting PING_REQUIRED=FALSE in /etc/init.d/minion to force it to skip executing the ensure-user-ping.sh script which requires root privs.
I'm not sure what the best long term fix for this should be.