Restricting axon-agent Privileges

This page describes how to remove the Linux capabilities that the packaged axon-agent systemd unit grants by default, for environments with a policy against granting file capabilities to service accounts.

The change is optional. The axon-agent process already runs as the unprivileged axonops user rather than root, and the capabilities described here narrow what that user can do within a defined boundary. Removing them is a deliberate hardening step for sites whose security policy prohibits ambient capabilities on service accounts, not a general recommendation.

The agent package and its systemd unit are the same whether axon-agent reports to AxonOps Cloud or to a self-hosted axon-server, so this procedure applies to both.

Prerequisites

axon-agent version 2.0.27 or later installed from the deb or rpm package, as described in axon-agent Installation. The procedure does not apply to container deployments, which do not use the packaged systemd unit.
Root or sudo access on each node.
No backup or restore job running against the node. Applying the change restarts axon-agent, which may interrupt any operation the agent is running at the time.

The change must be applied per node, and may be re-applied safely: systemctl edit reopens an existing drop-in for editing rather than creating a second one.

Default capability grant

The deb and rpm packages install a unit at /usr/lib/systemd/system/axon-agent.service. Its [Service] section is:

[Service]
WorkingDirectory=/usr/share/axonops

User=axonops
Group=axonops

ExecStart=/usr/share/axonops/axon-agent
Restart=always
RestartSec=5s
AmbientCapabilities=CAP_CHOWN CAP_FOWNER

Nice=10

The AmbientCapabilities=CAP_CHOWN CAP_FOWNER line grants additional permissions to axon-agent beyond what the axonops user would normally have.

CAP_CHOWN bypasses ownership restrictions on chown(2). CAP_FOWNER bypasses owner checks on chmod(2) and similar calls. Together they let axon-agent, running as axonops, change ownership and permissions on Cassandra data directories and restored SSTable files that the axonops user does not itself own. This is what allows a default installation to perform a backup restore without a manual chmod or chown step before and after.

Inspecting the installed unit

systemctl cat shows the packaged unit together with any drop-in overrides, and is the way to confirm what a given installation grants rather than relying on this page across package upgrades:

systemctl cat axon-agent.service

To determine whether the change will affect restores on a given node, check whether the axonops user can already write to the Cassandra data directory:

sudo -u axonops test -w /var/lib/cassandra/data && echo writable || echo "not writable"

If the directory is already writable, removing the capabilities does not change restore behaviour on that node. If it is not, restores will require the manual permission steps described below. Substitute the actual paths where the node uses a different data_file_directories setting, and check each one.

What removing the capabilities changes

With CAP_CHOWN and CAP_FOWNER absent, axon-agent skips permission and ownership changes during backup restore operations and logs a warning at the point it would otherwise have made them. The affected operations are Cassandra restore (local and remote), point-in-time restore and commitlog replay.

When the agent cannot already write, restoring requires the manual pre- and post-restore chmod/ chown steps described in Setting data directory permissions and in the point-in-time recovery overview.

Without the capabilities and without the manual chmod, the agent cannot write into the data directory and the restore will fail. If the pre-restore chmod g+w is applied but the post-restore chown is omitted, the restored files remain owned by axonops rather than by the Cassandra user, and Cassandra may be unable to read or compact them after it restarts. Both steps must be completed.

Only the Cassandra restore paths use these capabilities. axon-agent does not change ownership or permissions on Kafka log directories, so removing the capabilities has no effect on a Kafka-only deployment.

Removing the capabilities

Create a drop-in override for the axon-agent service. This writes a separate overlay file rather than modifying the packaged unit, so the change survives package upgrades:
Terminal window
```
sudo systemctl edit axon-agent.service
```
In the editor, add the following section, assigning an empty value to reset the ambient capability list:
```
[Service]
AmbientCapabilities=
```
Because AmbientCapabilities is the unit’s only privilege grant and the service already runs as the unprivileged axonops user, clearing it removes both capabilities.
Save the file and exit the editor. systemd reloads the unit configuration automatically.
Restart the service to apply the change:
Terminal window
```
sudo systemctl restart axon-agent
```

Verifying the change

First confirm the service came back up. A failed restart makes the later checks report misleading results:

systemctl is-active axon-agent

Confirm the resolved directives:

systemctl show axon-agent --property=AmbientCapabilities --property=CapabilityBoundingSet

Confirm the running process holds no effective capabilities by reading its CapEff field, the same field axon-agent itself reads:

sudo grep CapEff /proc/$(systemctl show axon-agent --property=MainPID --value)/status

A value of 0000000000000000 indicates no effective capabilities. The command is run with sudo because reading another user’s entry under /proc may be restricted on hosts mounted with hidepid.

Reverting

Remove the drop-in and restart the service:

sudo systemctl revert axon-agent.service
sudo systemctl restart axon-agent

Confirm the capabilities are back by re-running the checks in Verifying the change. AmbientCapabilities should report CAP_CHOWN CAP_FOWNER again, and the CapEff value should be non-zero.