Pkexec: use a single password prompt & implement a complete bluetooth toggle

Ask Fedora
, , , , , , ,
1

Hi,

I use a custom desktop entry for enabling and disabling bluetooth using systemctl.

KDE Plasma has a toggle using rfkill, so that may be fine, but better be paranoid than sorry :smiley: and it works really well.

What it does is enable or disable the bluetooth service, and mask or unmask it, to be extra sure.

This results in 2 password prompts, which is suboptimal.

How could I spawn a pkexec GUI password prompt, pipe that password into some file and just use sudo for the other one, piping the password there?

Into what file, how to protect it? Just a tempfile and delete it after piping? Or use it as a variable in both commands?

I should possibly overthink this:

  1. Changing the bluetooth service to a user systemd service would allow users to control it.
  2. Using a general “pkexec” prompt would not allow using dedicated groups for certain actions, locking users to the wheel group.

Solution without wheel group:

# copy the service
sudo cp /usr/lib/systemd/system/bluetooth.service /etc/systemd/user/bluetooth-user.service

# disable the system service
sudo systemctl disable --now bluetooth
sudo systemctl mask bluetooth

systemctl --user daemon-reload
systemctl --user enable --now bluetooth-user
2

Added systemd

3

Writing the password to a file doesn’t sound like a good idea. Even if you delete the file after the commands are executed it might still be recoverable (think software as recuva). Another problem is that a random process could read the file during the short time that it exists.

But unless I am missing something, cant you just start a shell session that executes both commands?

pkexec sh -c "systemctl disable --now bluetooth && systemctl mask bluetooth"
2 Likes
4

thanks! This is the solution for keeping the traditional bluetooth service (for whatever reason).

I edited both files and will personally now use the user service

strange, it worked first, now the service fails to start.

Also I noticed that all SELinux contexts are set to unconfined for /etc/systemd/user/ services I created myself. This needs fixing too

5

Added docs-team

6

This would also be cool as a quick doc