Continues prompting for password even if set NOPASSWD in sudoers

Bug #1074807 reported by Pedro
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
muon (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Im running kubuntu 12.10 and i see that muon continues asking for the password even after i have set NOPASSWD in sudo at /etc/sudoers

I see that synaptic doesnt prompt for password anymore and i also see that synaptic has a file to set polkit policy:

:~$ dpkg -L synaptic|grep policy
/usr/share/polkit-1/actions/com.ubuntu.pkexec.synaptic.policy

In muon theres no such file, but i also see that in the window that prompts the password appears in details lists what polkit policies uses:
Action: Install or remove packages
Supplier: Kubuntu
polkit.subject-pid: 9081
polkit.caller-pid: 9088

So i have tried to put those polkit policies as the ones from synaptic but it did not made any difference.
Also created a file for muon like the one from synaptic (in which i replaced synaptic for muon) -> /usr/share/polkit-1/actions/com.ubuntu.pkexec.muon.policy

and it also continued prompting a password when hitting the apply button.

Revision history for this message
Harald Sitter (apachelogger) wrote :

Please consult the ubuntu or kubuntu forums on how to set a polkit policy. Muon uses it differently than synaptic. In particular Muon has on-demand authentication so each action has a separate authentication level. Also see /usr/share/polkit-1/actions/org.kubuntu.qaptworker.policy

Changed in muon (Ubuntu):
status: New → Invalid
Pedro (simplew8)
Changed in muon (Ubuntu):
status: Invalid → Confirmed
status: Confirmed → New
Changed in muon (Ubuntu):
status: New → Invalid
Revision history for this message
Pedro (simplew8) wrote :

I have set the muon polkit policies for muon and i did changed then for admin and it did not mad eany difference.
Muon was not able to follow the defined polkit policy, isntead continued prompting the password.

Still i have even set qaptworker in "allow_any" for admin and that did not changed any, password continued being prompted, but all this should be unnecessary, since it should simply follow polkit sudo policy that sets the user for sudo group, thus running as administrator, and since in /etc/sudoers is set with NOPASSWD it should not prompt for the password.

Changed in muon (Ubuntu):
status: Invalid → New
Revision history for this message
Pedro (simplew8) wrote :

I wasnt that clear in previous comment and the first 2 paragraphs can induce in confusion, to clarify i did set /usr/share/polkit-1/actions/org.kubuntu.qaptworker.policy all action's with:

      <allow_inactive>auth_admin</allow_inactive>
      <allow_active>auth_admin</allow_active>
      <allow_any>auth_admin</allow_any>

and when applying any change in muon it prompted the password and that is not whats should happen, i.e. /etc/sudoers is set for NOPASSWD.

Revision history for this message
Jonathan Thomas (echidnaman) wrote :

The defaults need to be this to allow non-admin users to run actions:

<defaults>
         <allow_inactive>no</allow_inactive>
         <allow_active>yes</allow_active>
</defaults>

Specifying auth_admin for the allow* tags means that only a user authorized as admin can run the action.

Changed in muon (Ubuntu):
status: New → Invalid
Revision history for this message
Pedro (simplew8) wrote :

Êxactly, thats what i have been saying, im set as admin and i have password disabled in sudoers still muon continues to prompt for a passwaord.
I dont understand why are you stating that, did i referred it was to run as a reguler user?!

Changed in muon (Ubuntu):
status: Invalid → New
Revision history for this message
Pedro (simplew8) wrote :

For what i have checked, doesnt matter what policy you set, it always prompt for a password.
Muon/qapt are failing to follow whats set in sudo, but that doesnt depend on the set policy, it depends only on whats in /etc/sudoers.

If for example is set to run as admin_auth doesnt is to prompt for a password, it means its to run as admin, and the admin is set to not be prompted with password, so theres here something failing.

Can you explain me why this bug has been set as an invalid one?

Revision history for this message
Harald Sitter (apachelogger) wrote :

Because auth_admin has absolutely nothing to do with sudo but with the fact that you would have to authenticate as admin (i.e. the account that makes the request needs to be in an adminesque group such as 'admin' and the user needs to authenticate as being the owner of the account by means of passphrase).

Simply put you need to authenticate as admin, hence why it is called auth_admin.

Changed in muon (Ubuntu):
status: New → Invalid
Revision history for this message
Harald Sitter (apachelogger) wrote :

Actually let me clearify... polkit in general has absolutely nothing to do with sudo.

Revision history for this message
Pedro (simplew8) wrote :

When you use "auth_admin" is to enter as admin, now when becoming admin you have set sudoers to NOPASSWD then you should not be prompted with any password.
And this is what happens with the remaining applications, for example synaptic, that is set also set "auth_admin" doesnt prompt any password.

And another thing, muon/qapt are failing to follow any polkit policy, i have tested all situations and it always behaved the same way.

Im not going to change again the bug status, but i would hope you could investigate and see this as a real problem.

Revision history for this message
Pedro (simplew8) wrote :

And please take the most important thats the global policy, thats to use sudo group, that can be checked in 'kcmshell kcm_polkitconfig'

Ff the default is set to group sudo and if you belong to sudo group, and sudo is set to NOPASSWD, then should not prompt any password, this is clear enough, just hope you can understand it.

also take a look at /etc/polkit-1/localauthority.conf.d/{51-ubuntu-admin.conf,75-polkitkde.conf} where you can see default:

AdminIdentities=unix-group:sudo

Revision history for this message
Harald Sitter (apachelogger) wrote :

Because auth_admin has absolutely nothing to do with sudo but with the fact that you would have to authenticate as admin (i.e. the account that makes the request needs to be in an adminesque group such as 'admin' and the user needs to authenticate as being the owner of the account by means of passphrase).

^

AdminIdentities does exactly what I wrote there, specify which groups and/or accounts are considered an admin. If the requester is not part of the AdminIdentities they are not getting in, if they fail to provide the password for the account they are also not getting in. And it still has no other relation to sudo other than ubuntu having a group sudo which is qualifying as adminesque.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.