Skip to content

SysD Manager Proxy

Jump to bottom
Pier edited this page Mar 19, 2026 · 16 revisions

Why

SysD Manager uses a privileged proxy daemon to perform system-level operations that require root access. Because the SysD Manager, as a GTK4 GUI can't run directly as root.

Context

The /usr/share/dbus-1/system.d/org.freedesktop.systemd1.conf file is a D-Bus policy configuration file used by systemd, the system and service manager for Linux. It defines access permissions for the org.freedesktop.systemd1 D-Bus interface, which is central to controlling and monitoring systemd-managed units, jobs, and system state.

How the Proxy works

The Proxy is systemd service running as root on the system bus. It forwards Sysd Manager D-Bus methods to systemd.

Architecture diagram and Flow

See the Architecture page for detailed diagrams.

Polkit policies

The first Proxy call raise a polkit identification window. Subsequent calls does't require authentication.

Polkit Authentication

The first privileged operation triggers a polkit authentication dialog requesting the administrator password. The polkit policy uses auth_admin_keep, so subsequent operations in the same session are authorised automatically without prompting again.

The policy file is installed at /usr/share/polkit-1/actions/io.github.plrigaux.SysDManager.policy.

Proxy Lifecycle

The proxy runs as a systemd service. You can inspect it with Sysd Manager or with standard systemd tooling:

  systemctl status sysd-manager-proxy

  journalctl -u sysd-manager-proxy

The Proxy starts :

  • Manually
  • At SysD Manager startup
  • At requested calls

The Proxy stops :

  • Manually
  • At SysD Manager closing
  • When Sysd Manager is not more detected (Not implemented yet)

What operations go through the proxy

Each operation is individually configurable through Preferences. Users can choose per-operation whether to use the Proxy or fall back to default calls as configured by the local environment (D-Bus policy configuration, Polkit policies).

D-Bus methods exposed by the proxy:

Method Description
start_unit Start a system unit
stop_unit Stop a system unit
restart_unit Restart a system unit
clean_unit Clean a unit's runtime/cache/logs
freeze_unit Freeze a unit's processes
thaw_unit Thaw a frozen unit
enable_unit_files_with_flags Enable unit file(s)
disable_unit_files_with_flags Disable unit file(s)
revert_unit_files Revert unit file(s) to vendor defaults
reload Reload the systemd daemon

File action

  • save-file
  • revert-unit-file

Note user session calls doesn't pass trough the Proxy. i.e. If the Unit is on the System bus, the operation (user configured) goes trough the Proxy.

Frequently Asked Questions (FAQ)

Q: Why there is no proxy with Flatpak?

Flatpak's sandbox cannot launch processes as root.

Q: Is the Proxy is safe and secure?

No

Q: Why the Proxy isn't safe and secure?

For many reasons:

  • As a GNU General Public License v3.0 it offers no warranties
  • As a program running as root, it increases the attract surface
  • It accesses with read and write permission local files at root level

Q: What are the mitigation strategies to make the Proxy more secure?

  • The Proxy can only be started on demand (when it is needed)
  • The save file path are constrained to default path, namely :
    • /usr/lib/systemd/system
    • /etc/systemd/system/
    • /run/systemd/system
  • The Proxy can be closed automatically when SysD Manager closing
  • The Proxy close automatically when it lost connection with SysD Manager (Not yet implemented)
  • It requires a polkit authentification

Clone this wiki locally