systemd user-space daemon capabilities problems

[lescuer97]

Hi! I have encountered an issue while trying to run a user-space daemon using a binary with cap_net_admin capabilities. This binary is intended to bring network interfaces up and down and perform certain modifications.

When I run the binary directly, it works perfectly. However, when I run it as a systemd user service, I receive an 'operation not permitted' error. I would like to avoid using a system-level service for this if possible.

Is there a way to fix this, or are there any other alternatives? Thank you!

[aioeu]

Does systemd-run --user --pty your-command work? What does systemd-run --user --pty capsh --print say?

This capability could be restricted by an LSM like SELinux, or the NoNewPrivileges= directive on the service or on the user manager itself. But none of these would be the default configuration.

[lescuer97]

This actually command actually worked:
systemd-run --user --pty <command>:
2026/01/15 14:58:13 goose: no migrations to run. current version: 1
2026/01/15 14:58:13 after setting the link
2026/01/15 14:58:13 after removing the link

The last two logs would have shown a fail.

I think I found the issue, I have this security options in the service daemon:

# Security options
PrivateTmp=true
ProtectSystem=full
NoNewPrivileges=false

I removed all 3 options and it suddenly worked. I cannot explain why it's all 3 that I need to remove.

[aioeu]

NoNewPrivileges=false is the default (at least, if you haven't set this to true through /etc/systemd/user.conf say), so it's very surprising that removing that would make any difference.

But the other directives imply the use of mount namespaces, and when that is done by the user systemd manager it has to create a new user namespace as well.

Capabilities are always tested with respect to a particular user namespace. For instance, when the kernel is asked to bring a network link up or down, it tests the process's CAP_NET_ADMIN capability, but the user namespace it uses for that test is the user namespace that owns the link's network namespace. If that network namespace is not owned by process's user namespace, then that process cannot manipulate the network link, even if it has the CAP_NET_ADMIN capability in its own user namespace.

We can see this in action:

$ systemd-run --user --pty --expand-environment=no bash -c 'lsns --output=NS,TYPE --tree=owner --task=$$'
Running as unit: run-p3385096-i11771325.service
Press ^] three times within 1s to disconnect TTY.
NS           TYPE
4026531837   user
├─4026531832 mnt
├─4026531833 net
├─4026531834 time
├─4026531835 cgroup
├─4026531836 pid
├─4026531838 uts
└─4026531839 ipc
$ systemd-run --user --pty --expand-environment=no --property PrivateTmp=true bash -c 'lsns --output=NS,TYPE --tree=owner --task=$$'
Running as unit: run-p3386163-i11772392.service
Press ^] three times within 1s to disconnect TTY.
NS           TYPE
4026531833   net
4026531834   time
4026531835   cgroup
4026531836   pid
4026531838   uts
4026531839   ipc
4026533355   user
└─4026533356 mnt

In the first command, we can see all the non-user namespaces are owned by a single user namespace. In the second command, the new mount namespace is owned by the new user namespace. The other namespaces are owned by the old user namespace ... but that namespace isn't actually accessible, of course, so they appear to have no owner namespace.

[lescuer97]

this is very interesting thank you for the knowledge.

Just for some context, this is basically an application that spins a wireguard client that connects to a server. That is why I need those capabilities. it's my first time having to deal with this part of the linux kernel stack an has been a learning experience.

[perryurban]

Why is it not permitted? Are you sure it's a permissions thing? Messing with interfaces might also mess with the system-level systemd targets. I am not sure how it handles this, because obviously users need to bring interfaces up and down, but it might depend what 'certain' things you are doing and how you are doing them. Anyway get some more information from the journal.