Use userspace systemd (systemctl)

[RoderickGreening-Rogers]

I wonder if its possible to avoid requiring admin/sudo for decky plugin if we look at userspace systemd?

https://wiki.archlinux.org/title/systemd/User

I don't know if this is technically feasible or not, but if it is, maybe its worth a look?

Cheers

[WerWolv]

This is not possible because there are various plugins that require root access which in turn requires Decky to run as root

[zamu-flowerpot]

Just trying to make sure all the options for running as root are documented online, so preemptive sorry if they've been discussed to death elsewhere.

Have we looked into the follow instead of using root:

• Using setcap on the plugin binaries at install time
• Similarly, utilizing systemd service files to run the processes under a separate user namespace (ie. the PrivateUser= directive) and setting capabilities within (ie. AmbientCapabilities= and/or CapabilityBoundingSet= directives).
• Running the plugins within a podman container with the IPC and shared memory requirements mounted

---

I'm particularly not interested in podman containers, but using setcap or systemd user services should be something in the realm of possibility.

[AAGaming00]

Just trying to make sure all the options for running as root are documented online, so preemptive sorry if they've been discussed to death elsewhere.

Have we looked into the follow instead of using root:

• Using setcap on the plugin binaries at install time
• Similarly, utilizing systemd service files to run the processes under a separate user namespace (ie. the PrivateUser= directive) and setting capabilities within (ie. AmbientCapabilities= and/or CapabilityBoundingSet= directives).
• Running the plugins within a podman container with the IPC and shared memory requirements mounted

---

I'm particularly not interested in podman containers, but using setcap or systemd user services should be something in the realm of possibility.

This only provides a false sense of security, a malicious decky loader binary could always just use these same methods to elevate to root.

[zamu-flowerpot]

Not really? Root gives them access to everything, on the other hand if they only have a smaller set of capabilities they can only do what they were configured to. For example, a fan curve plugin can't modify network configuration without network admin capabilities, but root access would let them. Additionally, we can lock their capabilities once set so they can't increase their capability set at runtime.

Additionally, the malicious plugin would have to do so at install time to raise their own capabilities (and even then it'd be decky-loader that does so, so we can block certain capabilities outright and review them before adding them to the store).

---

Sorry if this seems combative I just rather limit the root access to just decky-loader, if it's absolutely necessary. I rather inspect just one code base than every plugin since some of the plugins do have network access.

[AAGaming00]

Possibly setting process caps for plugins could be explored, but I'd rather not go further than that.

[RoderickGreening-Rogers]

As plugins are pseudo external (yes review added but externally developed), there is more risk to carte blanche root at decky level IMO vs elevated/locked rights per pkugin.

Personally i only need plugins without admin but decky requires it presently.