Privileges and permissions

CaudalGhost needs privileges for two specific kernel-level things, and it asks for them as narrowly as possible. Day to day, you don’t need sudo.

Why it asks for privileges during install

Installation runs with privileges (sudo) because it:

• Registers the daemon’s systemd service.
• Creates the service user/group caudalghost.
• Installs a permission rule (polkit) and the service configuration.

This happens once, at install or upgrade time.

Why you don’t need sudo afterward

The daemon runs without root, as a service with minimal capabilities:

• CAP_BPF / CAP_PERFMON (via systemd’s AmbientCapabilities): just enough to attach eBPF kprobes and read kernel metrics. Nothing more. It doesn’t use setcap on loose binaries, and it doesn’t inherit any other root privilege.
• No TCP port, no web server: clients (CLI, TUI, GUI) talk to the daemon over a local Unix socket. There’s no listening port or network surface to expose.
• The systemd unit locks down networking: the service runs with RestrictAddressFamilies limited to AF_UNIX/AF_NETLINK, so it can’t even open an outbound network socket even if it wanted to.
• Socket access without sudo (desktop): in the desktop edition, the daemon grants your user session access to its socket automatically (by UID, refreshed every few seconds). That’s why the GUI and CLI work without elevating privileges. In the server edition, this automatic access is turned off by default (see below).

Hostname resolution via polkit

To turn IPs into hostnames, the daemon subscribes to query results from the system resolver (systemd-resolved). That access is gated by polkit, not by UID: an installed rule (org.freedesktop.resolve1.subscribe-query-results) authorizes the service. If the resolver isn’t available, CaudalGhost degrades gracefully and shows raw IPs instead of failing.

Access on multi-user machines (server edition)

CaudalGhost measures traffic for the whole machine, not per user. On a desktop (single user), that’s exactly what you want: install it, open it, and it works. On a server with multiple users, it’s worth deciding who gets to query that telemetry, so each edition ships with a different default:

• Desktop edition: the daemon grants socket access to your session automatically (by UID).

• Server edition (headless): UID-based access is off by default. Only the caudalghost group gets socket access, and the admin adds trusted users explicitly:

  sudo usermod -aG caudalghost <username>

  (Whoever installs the package is already in the group.)

Allowing access for every logged-in user

If you genuinely want any logged-in user to be able to query the telemetry (say, a trusted shared workstation), turn it on intentionally:

sudo systemctl edit caudalghostd

and add the override:

[Service]
Environment=CAUDALGHOST_ACL_ACTIVE_USERS=1

Then run sudo systemctl restart caudalghostd.

Privacy implication

With this on, any logged-in user can see which IPs and domains every application is connecting to, for all users on the machine. The daemon logs a warning about this every time it starts up with this mode active. To go back to the restricted mode: sudo systemctl revert caudalghostd and restart.

It observes, never interferes: this only decides who can read the measurements; CaudalGhost never blocks or modifies traffic.

Summary

When	Privilege	Why
Install / upgrade	with privileges (sudo)	register the service, user, polkit rule
Daemon running	CAP_BPF/CAP_PERFMON (no root)	attach kprobes and read eBPF metrics
Client↔daemon communication	Unix socket (no TCP port)	CLI, TUI, and GUI talk over local IPC
Resolving hostnames	polkit rule	subscribe to systemd-resolved
Using the GUI / CLI (desktop)	none	socket access via your UID
Multi-user server	caudalghost group	decide who can read the telemetry

It observes, never interferes: none of these capabilities let CaudalGhost block, modify, or inject traffic. Only read and measure.