Ask Your Question

Can't perform polkit-elevated actions with AD user in wheel group

asked 2016-02-06 13:19:56 -0500

Lux Liquidus gravatar image

I have my Fedora 23 box joined to an AD domain using SSSD. My AD user is in the local wheel group on this machine.

I'm able to login normally, and I'm able to sudo normally from a terminal. But when I try to do something that's managed by polkit, like mounting a NTFS partition, it fails with a message like "Authentication failure, please try again."

This happens in both Gnome and KDE/Plasma, and it seems to happen for any elevation prompt (i.e. any time Gnome or KDE prompts me to enter in my password because I'm doing something normal users aren't allowed to do).

I haven't changed the default polkit rules, so wheel is still the default admin group:

polkit.addAdminRule(function(action, subject) {
    return ["unix-group:wheel"];

The only thing logged in /var/log/secure is something like this each time it fails:

Feb  6 14:10:44 river polkit-agent-helper-1[5429]: pam_sss(polkit-1:auth): authentication success; logname= uid=1023801104 euid=0 tty= ruser=myuser rhost= user=myuser
Feb  6 14:10:44 river polkit-agent-helper-1[5429]: pam_sss(polkit-1:account): Access denied for user myuser: 6 (Permission denied)
Feb  6 14:11:14 river polkitd[996]: Operator of unix-session:1 FAILED to authenticate to gain authorization for action org.freedesktop.udisks2.filesystem-mount-system for system-bus-name::1.135 [/usr/bin/dolphin] (owned by unix-user:myuser)

I'm happy to provide any other logs or details that might be helpful investigating the problem.

Anyone seen something like this before, or have any hints about why it's failing?

edit retag flag offensive close merge delete

3 Answers

Sort by ยป oldest newest most voted

answered 2016-02-06 15:06:22 -0500

updated 2016-02-06 15:07:46 -0500

The distribution policy is set in /usr/share/polkit-1/actions/org.freedesktop.udisks2.policy; you can override packaged policies by copying such files to the equivalent path in /etc/polkit-1. afaik, you need to do that per action; I'm not aware of polkit magic for "let my superuser do all the things".

I found that because I know that vendor policy is in /usr/share/polkit-1, and your log message reports an attempted action of org.freedesktop.udisks2.filesystem-mount-system, so grep -r org.freedesktop.udisks2.filesystem-mount-system /usr/share/polkit-1 turned up the relevant file.

edit flag offensive delete link more


Thanks for the response!

I looked at the file you referenced (/usr/share/polkit-1/actions/org.freedesktop.udisks2.policy) and it contained this entry:

  <action id="org.freedesktop.udisks2.filesystem-mount-system">

If I'm understanding the documentation right, that should allow anyone registered as an admin user (i.e. anyone in the wheel group) to perform the action. Am I missing something?

Lux Liquidus gravatar imageLux Liquidus ( 2016-02-06 15:23:30 -0500 )edit

Whoops, I missed a step, will update the answer.

randomuser gravatar imagerandomuser ( 2016-02-09 23:14:42 -0500 )edit

Actually, I realized that the action file isn't as relevant as the rule definition; /etc/polkit-1/rules.d/50-default.rules should trigger those default allowances you cited via membership in wheel - like you said in the first place.... I'd start with getting the basics our of the way, ie sss_cache -E; dnf update; rpm -Va; fixfiles onboot && reboot. Your pam configuration might come into play as well.

randomuser gravatar imagerandomuser ( 2016-02-09 23:34:02 -0500 )edit

answered 2016-02-06 13:58:08 -0500

sideburns gravatar image

If you installed Fedora, you had to give it a root password and should know it. Try using su instead, giving the root password instead of your own. If you just need to give one command, do it like this: su -c 'command argument argument' so that you won't remain root after you're done. The sudo command, really, is just a substitute for people who aren't trusted with root, and wasn't designed as a complete replacement for working as root to allow them to do various minor chores that regular users can't normally do.

edit flag offensive delete link more


Thanks for the response, but I think you misunderstand -- sudo works normally. It's things that Gnome/KDE automatically require elevation for in the GUI that are not working. If I perform the equivalent commands using sudo in a terminal, it all works fine.

Lux Liquidus gravatar imageLux Liquidus ( 2016-02-06 15:12:06 -0500 )edit

answered 2016-07-17 18:35:26 -0500

You can fix this by editing your sssd.conf file and adding

ad_gpo_map_permit +polkit-1

to the AD section.

It has been fixed in SSSD-1.14, which will be in F25.

edit flag offensive delete link more

Question Tools



Asked: 2016-02-06 13:19:56 -0500

Seen: 1,447 times

Last updated: Feb 06 '16