Convert Bluetooth (and other) systemd services to user services

Ask Fedora
, , , , , ,
1

There are many things that typical users should be able to enable or disable, for example Bluetooth.

There may be a big difference between the traditional idea of a system, an admin and many unprivileged users, and how it is done today.

Systemd user services allow:

  • to disable or enable services without root
  • to have different states between users

This works towards my goal of making the system usable without wheel access.

Desktops have other workarounds but I think they are not clean. KDE Plasma for example uses rfkill to disable Bluetooth, while the systemd service is still running. Disabling the service hides the Bluetooth applet.

I tried the following:

  1. Copy the service file to/etc/systemd/user
  2. Disable and mask the system service
  3. Enable the user service

But it doesnt work yet, will add the errors in time.

Did anyone experiment with this? What do you think of this idea?

2 Likes
2

I admit, I didn’t go into this stuff deeply yet, and I am definitely not an expert in how our os manages Bluetooth compared to other technologies anyway. But when I read this, the first thing I have in mind is the Bluetooth issue we have with SELinux user confinement.

I have already provided data in two topics that I back then considered to be related: several issues, one origin. Because of that (and because of a lack of time :frowning: ) I never created a dedicated ticket for Bluetooth but kept the elaboration with Zdenek in another ticket:
#1829 (check primarily the later posts; the related posts have some outreach to #1846).

Now that the button issues have been solved while the Bluetooth issue I elaborated in the ticket has changed but still remains, I assume it is indeed worth a dedicated ticket (thanks for the reminder!). And I also started to assume that maybe it is indeed related to the rtkit denials (I expected a different relation earlier, but that possibility seems to be obsoleted since the buttons work again in F40).

In any case, SELinux user confinement is a great possibility to verify if things are configured properly and with a “good practice”. If your argument is right that Bluetooth stuff is a little “ugly” in its configuration, it could also explain why SELinux doesn’t “like it”. Of course this is just one possibility, and some yet not identified labels remain the other :wink:

If you keep playing with this, feel free to keep us updated.

3

A post was split to a new topic: Brainstorm: Confined users without wheel access

4

Haha Bluetooth is kinda fine.

All the stuff in /etc/xdg/autostart is ugly, not managed with systemd, somehow still launched even when removed, I have no idea how that works.

5

bluetoothd already runs as a dedicted service. The service is locked down quite a bit, but it still requires CAP_NET_ADMIN and CAP_NET_BIND_SERVICE. So I don’t think it makes sense to try to run it unprivileged.

What KDE is doing doesn’t make much sense… Just change it to stop and start the service normally.