If I remove myself from the wheel group, won't that prevent me from using sudo? Are there similar ramifications if I remove /etc/polkit-1/rules.d/50-default.rules ? (And what does that file do exactly?)

> If I remove myself from the wheel group, won't that prevent me from using sudo?
No. Yes. Depends on the sudoers file. Not in general. Usually not.
journalctl will start asking for passwords, but I assume that's gonna happen as well when removing /etc/polkit-1/rules.d/50-default.rules

Right now, that file should only move users in the wheel group into the admin category. Preventing that will (should unless bug) make polkit ask for the root password rather than the user password.

I used a test account, and it was unable to sudo unless it was in the wheel group.

What if I leave things as they are? Would any other programs apart from gparted use the "user" password instead of root's? I'm not particularly fussed if gparted can be run with minimal authentication, but there might be others? I'm not sure if I'm looking in the right area, but `/usr/share/polkit-1/actions` contained the following files. None of the processes looked particularly sensitive?

Code: Select all

com.ubuntu.pkexec.gufw.policy
org.archlinux.pkexec.gparted.policy
org.archlinux.pkexec.unetbootin.policy
org.freedesktop.color.policy
org.freedesktop.hostname1.policy
org.freedesktop.locale1.policy
org.freedesktop.login1.policy
org.freedesktop.ModemManager1.policy
org.freedesktop.NetworkManager.policy
org.freedesktop.policykit.examples.pkexec.policy
org.freedesktop.policykit.policy
org.freedesktop.RealtimeKit1.policy
org.freedesktop.systemd1.policy
org.freedesktop.timedate1.policy
org.freedesktop.udisks2.policy
org.gnome.gconf.defaults.policy
org.jjk.kalu.policy
org.kde.baloo.filewatch.policy
org.kde.fontinst.policy
org.kde.kalarmrtcwake.policy
org.kde.kcontrol.kcmclock.policy
org.kde.kcontrol.kcmkdm.policy
org.kde.kcontrol.kcmkwallet.policy
org.kde.kcontrol.kcmremotewidgets.policy
org.kde.ksysguard.processlisthelper.policy
org.kde.powerdevil.backlighthelper.policy
org.x.xf86-video-intel.backlight-helper.policy


sparhawk wrote:I used a test account, and it was unable to sudo unless it was in the wheel group.

That means your sudoers contains an uncomment "%wheel" line but no configuration for the particular user, sth. like
%wheel ALL=(ALL) ALL

You could just as well
%sudo ALL=(ALL) ALL

and add yourself to sudo or use
sparhawk ALL=(ALL) ALL

for your actual login only.

There's no hard restriction for a "wheel" group whatsoever.

Would any other programs apart from gparted use the "user" password instead of root's?

you may try "pkexec xterm" - you'll likely be asked for the user password... and have a rootshell =)

luebking wrote:

Would any other programs apart from gparted use the "user" password instead of root's?

you may try "pkexec xterm" - you'll likely be asked for the user password... and have a rootshell =)

This particular example didn't work, I got

Code: Select all

$ pkexec xterm
Warning: This program is an suid-root program or is being run by the root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
/usr/bin/xterm: Xt error: Can't open display: %s
/usr/bin/xterm: DISPLAY is not set


However, I take your point, and I'm not going to risk something similar being compromised.

luebking wrote:

sparhawk wrote:I used a test account, and it was unable to sudo unless it was in the wheel group.

That means your sudoers contains an uncomment "%wheel" line but no configuration for the particular user, sth. like
%wheel ALL=(ALL) ALL

You could just as well
%sudo ALL=(ALL) ALL

and add yourself to sudo or use
sparhawk ALL=(ALL) ALL

for your actual login only.

There's no hard restriction for a "wheel" group whatsoever.

I tested the latter on my test account, and it seems to work well. I only have need for one sudo-capable user, so I'm happy to manually specify the users like this. However, I'm a little confused now as to what I'm doing, with reference to your earlier post, quoted here:

luebking wrote:Ah, that's because of /etc/polkit-1/rules.d/50-default.rules
Either remove that or your user from the wheel group.
(Be careful: i found bugreports that instead of asking for the root passwort, polkit just **** itself when you're not in wheel. No idea whether that's fixed)

So I've now manually given myself root access as above. Given that you've suggested that there are some potential problems if I remove myself from wheel, should I just remove /etc/polkit-1/rules.d/50-default.rules instead?

This particular example didn't work, I got

Missing environment setup, but that's indeed no general hinder (not even for xterm, just requires some env exports)

Given that you've suggested that there are some potential problems if I remove myself from wheel

That's a misunderstanding. There was a bug (and may still apply) that made polkit fail if it had to ask for the root password - for *any* reason.
Be it that you're not in the wheel group or that the wheel group is not considered "admin" by polkit.

If this bug hits you, you cannot use polkit by providing the root password.
If it doesn't there's no problem in any way making polkit ask you for the root password (be it removing yourself from %wheel or removing that polkit config snippet)

luebking wrote:
There was a bug (and may still apply) that made polkit fail if it had to ask for the root password - for *any* reason.
Be it that you're not in the wheel group or that the wheel group is not considered "admin" by polkit.

If this bug hits you, you cannot use polkit by providing the root password.
If it doesn't there's no problem in any way making polkit ask you for the root password (be it removing yourself from %wheel or removing that polkit config snippet)

Thanks for that. I've removed myself from wheel, and gparted appears to work fine now, asking for root's password. Just to confirm, is this confirmation that the bug didn't hit me, and I should be fine from now on?

Thanks again for all your help.

Just to confirm, is this confirmation that the bug didn't hit me

Yupp. Polkit would just have stalled otherwise.

Thanks again.