This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 855784 - packagekit waits for authentication forever is user is not in wheel group
packagekit waits for authentication forever is user is not in wheel group
Status: CLOSED DUPLICATE of bug 834494
Product: Fedora
Classification: Fedora
Component: gnome-packagekit (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
RejectedNTH
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-10 05:34 EDT by Kamil Páral
Modified: 2012-09-18 00:47 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-17 20:05:08 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Kamil Páral 2012-09-10 05:34:57 EDT
Description of problem:
If I use packagekit to install a new package, it is "waiting in queue" forever.
pkmon displays:

[kparal@localhost ~]$ pkmon
Transactions:
 [none]
daemon connected=1
network status=online
Transactions:
 1	/59_daccbaee
/59_daccbaee	allow_cancel 1
/59_daccbaee	percentage   -1
/59_daccbaee	role         get-repo-list
/59_daccbaee	status       wait
/59_daccbaee	status       finished
/59_daccbaee	exit code: unknown
Transactions:
 [none]
Transactions:
 1	/60_ceedbdcc
/60_ceedbdcc	allow_cancel 1
/60_ceedbdcc	percentage   -1
/60_ceedbdcc	role         search-details
/60_ceedbdcc	status       wait
/60_ceedbdcc	status       finished
/60_ceedbdcc	exit code: unknown
Transactions:
 [none]
Transactions:
 1	/61_debbebaa
/61_debbebaa	allow_cancel 1
/61_debbebaa	percentage   -1
/61_debbebaa	role         get-details
/61_debbebaa	status       wait
/61_debbebaa	status       finished
/61_debbebaa	exit code: unknown
Transactions:
 [none]



If I try the same using pkcon, it waits for authentication forever:

$ pkcon install htop
Installing                    [=========================]         
Waiting in queue              [=========================]         
Waiting for authentication    [                    ==   ] 


If I run pkcon as root, everything works as expected.


Version-Release number of selected component (if applicable):
PackageKit-yum-plugin-0.8.3-2.fc18.i686
PackageKit-0.8.3-2.fc18.i686
PackageKit-glib-0.8.3-2.fc18.i686
gnome-packagekit-3.5.90-1.fc18.i686
PackageKit-gstreamer-plugin-0.8.3-2.fc18.i686
PackageKit-yum-0.8.3-2.fc18.i686
PackageKit-gtk3-module-0.8.3-2.fc18.i686
PackageKit-command-not-found-0.8.3-2.fc18.i686
PackageKit-device-rebind-0.8.3-2.fc18.i686
yum-presto-0.9.0-1.fc18.noarch
yum-metadata-parser-1.1.4-7.fc18.i686
yum-3.4.3-42.fc18.noarch
yum-langpacks-0.3.0-2.fc18.noarch
yum-utils-1.1.31-6.fc18.noarch

How reproducible:
seems 100%
Comment 1 Kamil Páral 2012-09-10 05:35:48 EDT
Proposing Alpha blocker:
" The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops "
https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
Comment 2 Richard Hughes 2012-09-10 05:44:13 EDT
(In reply to comment #0)
> If I run pkcon as root, everything works as expected.

Smells like a PolicyKit issue then. Is the current session active or are you logged in with vnc / ssh?
Comment 3 Kamil Páral 2012-09-10 06:04:49 EDT
It is a standard session.

$ systemd-loginctl list-sessions
   SESSION        UID USER             SEAT            
         2       1000 kparal           seat0           

1 sessions listed.

PolicyKit version:
polkit-0.107-2.fc18.i686
polkit-gnome-0.105-3.fc18.i686
Comment 4 Tim Lauridsen 2012-09-10 07:28:29 EDT
It could be related to the issues yumex is having with polkit in F18

https://bugzilla.redhat.com/show_bug.cgi?id=834494

look like there is some difference in how polkit detect inactive/active in F18, so  what specified as <allow_active> in F17, must be <allow_inactive> in F18

I don't know if it supposed to be so or it is a bug in polkit ?
Comment 5 Jaroslav Reznik 2012-09-10 10:41:15 EDT
KDE PolicyKit agent works correctly. Try a different agent (for example kde one - polkit-kde). Or try command line tools to check if policykit works as expected. Other debugging possibility is to run polkitd manually to check errors/warnings.
Comment 6 Jaroslav Reznik 2012-09-10 11:17:58 EDT
With latest PackageKit I'm able to install packages on Gnome spin, auth agent popups correctly, password is accepted.
Comment 7 Tim Lauridsen 2012-09-10 12:30:34 EDT
Information about how the F18 system is installed, is useful to reproduce the problem. (Updated from F17 or some TC release ?)
Comment 8 Kamil Páral 2012-09-10 12:52:56 EDT
I have installed F18 Alpha TC4 (or something like that) and upgraded since then.
Comment 9 Adam Williamson 2012-09-10 12:58:39 EDT
Discussed at 2012-09-10 QA meeting, acting as a blocker review meeting. We agreed this needs more investigation as it doesn't seem to occur in all cases. We will revisit it after further tests.
Comment 10 Kamil Páral 2012-09-10 13:08:47 EDT
# journalctl -a | grep polkit
Sep 10 16:56:24 localhost dbus-daemon[411]: dbus[411]: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service'
Sep 10 16:56:24 localhost dbus[411]: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service'
Sep 10 16:56:24 localhost polkitd[475]: Started polkitd version 0.107
Sep 10 16:56:24 localhost polkitd[475]: Loading rules from directory /etc/polkit-1/rules.d
Sep 10 16:56:24 localhost polkitd[475]: Loading rules from directory /usr/share/polkit-1/rules.d
Sep 10 16:56:24 localhost polkitd[475]: Finished loading, compiling and executing 2 rules
Sep 10 16:56:24 localhost polkitd[475]: Acquired the name org.freedesktop.PolicyKit1 on the system bus
Sep 10 16:56:40 localhost polkitd[475]: Registered Authentication Agent for unix-session:1 (system bus name :1.35 [gnome-shell --mode=gdm], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale C)
Sep 10 16:57:18 localhost polkitd[475]: Unregistered Authentication Agent for unix-session:1 (system bus name :1.35, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale C) (disconnected from bus)
Sep 10 16:57:26 localhost polkitd[475]: Registered Authentication Agent for unix-session:2 (system bus name :1.72 [/usr/bin/gnome-shell], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Sep 10 16:57:57 localhost polkitd[475]: Operator of unix-session:2 FAILED to authenticate to gain authorization for action org.freedesktop.packagekit.package-install for system-bus-name::1.81 [<unknown>] (owned by unix-user:kparal)
Sep 10 16:58:08 localhost polkitd[475]: Operator of unix-session:2 FAILED to authenticate to gain authorization for action org.freedesktop.packagekit.package-install for system-bus-name::1.82 [<unknown>] (owned by unix-user:kparal)
Sep 10 16:58:34 localhost polkitd[475]: Operator of unix-session:2 FAILED to authenticate to gain authorization for action org.freedesktop.packagekit.package-install for system-bus-name::1.84 [<unknown>] (owned by unix-user:kparal)
Comment 11 Adam Williamson 2012-09-10 14:08:38 EDT
I can't reproduce this on my regular desktop system (yum upgraded from f17 and regularly yum updated since then), I can happily install packages from gnome-packagekit, the auth dialog pops up as expected. my user is an 'admin', so I'm prompted for user password, not root password.
Comment 12 Tim Lauridsen 2012-09-11 01:35:39 EDT
(In reply to comment #11)
> I can't reproduce this on my regular desktop system (yum upgraded from f17
> and regularly yum updated since then), I can happily install packages from
> gnome-packagekit, the auth dialog pops up as expected. my user is an
> 'admin', so I'm prompted for user password, not root password.

What arch are you running i686 or x86_64, just to rule out it somehow arch related, I have only see it on i686
Comment 13 Tim Lauridsen 2012-09-11 01:39:53 EDT
@kamil:

Try editing the /usr/share/polkit-1/actions/org.freedesktop.packagekit.policy

and change

<allow_inactive>no</allow_inactive> 

to 

<allow_inactive>auth_admin_keep</allow_inactive> 

for 

org.freedesktop.packagekit.package-install

And see if it works then
Comment 14 Kamil Páral 2012-09-11 07:15:36 EDT
I have found the problem, my user was not in the wheel group. When I add it to the wheel group, I see a pop-up asking for my password. If I provide it, everything works (pkcon and gui tool).

So the problem is that packagekit doesn't announce "your user doesn't have required priviledges" if the user is not in wheel group, but silently waits forever.

This is not a critical issue, canceling F18 Alpha blocker and re-proposing as Final NTH.
Comment 15 Tim Lauridsen 2012-09-11 09:26:22 EDT
Same issue with yumex, 

https://bugzilla.redhat.com/show_bug.cgi?id=834494

if the current user is in the wheel group, it work as expected, but if the user is not in the wheel group then polkit dont give a authentication dialog, it just hang forever.

This is not an Alpha blocker, but if the plan is to not have a root password on default installation, and the user don't select the first user to be an administrator, then the user will not be able to update or fix the issues.
So maybe it should be a final blocker.
Comment 16 Tim Lauridsen 2012-09-11 09:52:42 EDT
Just did a fresh installation of F18 Alpha RC2 netinst in VirtualBox, where i did not check the first user as administrator.

If you run

$ pkcon install htop
Installing                	[=========================]    	 
Waiting in queue          	[=========================]    	 
Waiting for authentication	[=========================]    	 
Fatal error: Failed to obtain authentication.

It will not hang, just give at error.

If you run the gui (gpk-application) it don't tell you nothing when apply changes, I just don't do anything. (Richard it would be nice to let the user know that authentication fails :) )

In yumex is also just get and error.

After adding the user to wheel group & rebooted, then every thing is working as expected.
Comment 17 Kamil Páral 2012-09-11 10:06:04 EDT
(In reply to comment #15)
> This is not an Alpha blocker, but if the plan is to not have a root password
> on default installation, and the user don't select the first user to be an
> administrator, then the user will not be able to update or fix the issues.
> So maybe it should be a final blocker.

That is already reported as bug 856194.
Comment 18 Adam Williamson 2012-09-11 12:30:45 EDT
Given that firstboot doesn't default to 'admin' user at present, I think quite a few people may hit this, so proposing as Alpha NTH. I'm also going to file a bug to have firstboot default to 'admin'.
Comment 19 Adam Williamson 2012-09-11 13:21:46 EDT
Kamil already filed such a firstboot bug, for reference, it's https://bugzilla.redhat.com/show_bug.cgi?id=856194 .
Comment 20 Adam Williamson 2012-09-11 21:02:22 EDT
Could this perhaps be related to https://bugzilla.redhat.com/show_bug.cgi?id=852403 ? Does it work in Permissive mode, or if selinux-policy is updated?
Comment 21 Adam Williamson 2012-09-12 00:26:51 EDT
Oh - and did you guys actually set a password for root?

If not, then PolicyKit is kind of stuck, because it has nothing it can do: the user can't be allowed to install packages with their own password, and there's no root password to ask for. So what can it do? I suppose the case where you have no root password and no admin user isn't a PK bug, really.
Comment 22 Tim Lauridsen 2012-09-12 00:37:45 EDT
(In reply to comment #21)
> Oh - and did you guys actually set a password for root?
> 
> If not, then PolicyKit is kind of stuck, because it has nothing it can do:
> the user can't be allowed to install packages with their own password, and
> there's no root password to ask for. So what can it do? I suppose the case
> where you have no root password and no admin user isn't a PK bug, really.

I have added a root password in my tests, so no root password is not the issue here.

I have tried to run setenforce 0, that don't changes anything.

But I will do some more testing later today
Comment 23 Adam Williamson 2012-09-12 01:07:52 EDT
OK, tested and this occurs in the case where you set a root password. PackageKit / PolicyKit should ask for the root password in this case. So it's a genuine bug. Also doesn't appear to be 852403 - it happens in Permissive.
Comment 24 Tim Lauridsen 2012-09-12 04:29:52 EDT
Did some testing with selinux in permissive mode.
It don't change anything.
it behaves a little different today, pkcon waits forever (had to press ctrl-c to abort) (no matter what selinux mode the system is running). I have updated the system with the latest updates from f18 updates-testing. 

[tim@localhost ~]$ sudo usermod -G tim tim
[tim@localhost ~]$ sestatus
SELinux status:             	enabled
SELinuxfs mount:            	/sys/fs/selinux
SELinux root directory:     	/etc/selinux/
Loaded policy name:         	targeted
Current mode:               	permissive
Mode from config file:      	permissive
Policy MLS status:          	enabled
Policy deny_unknown status: 	allowed
Max kernel policy version:  	28
[tim@localhost ~]$ pkcon install htop
Installing                	[=========================]    	 
Waiting in queue          	[=========================]    	 
Waiting for authentication	[    	==           	]     	^C
[tim@localhost ~]$ sudo usermod -G tim,wheel tim
[tim@localhost ~]$ pkcon install htop
Installing                	[=========================]    	 
Waiting in queue          	[=========================]    	 
Waiting for authentication	[=========================]    	 
Waiting in queue          	[=========================]    	 
Starting                  	[=========================]    	 
Running                   	[=========================]    	 
Resolving dependencies    	[=========================]    	 
Downloading update information[=========================]    	 
Installing packages       	[=========================]    	 
The following packages have to be installed:
 libpagemap-0.0.1-11.fc18.i686    Pagemap interface library
 htop-1.0.1-2.fc18.i686    Interactive process viewer
Proceed with changes? [N/y] n

The transaction did not proceed.
                          	[=========================]    	 
Fatal error: user declined simulation
Comment 25 Adam Williamson 2012-09-12 15:01:56 EDT
Discussed at 2012-09-12 NTH review meeting. Rejected as a blocker, there just wasn't enough sentiment that this is a serious enough problem to poke PK at such a late stage. Using yum is an obvious workaround, and a fix could be provided as an update to be installed with yum.
Comment 26 Richard Hughes 2012-09-14 10:59:53 EDT
(In reply to comment #23)
> OK, tested and this occurs in the case where you set a root password.
> PackageKit / PolicyKit should ask for the root password in this case. So
> it's a genuine bug. Also doesn't appear to be 852403 - it happens in
> Permissive.

Does this mean it's a PolicyKit bug then? Maybe duping with #834494 is a good idea?
Comment 27 Tim Lauridsen 2012-09-14 12:08:37 EDT
(In reply to comment #26)

> Does this mean it's a PolicyKit bug then? Maybe duping with #834494 is a
> good idea?

Sounds like a good idea :)
Comment 28 Adam Williamson 2012-09-17 20:05:08 EDT
Richard: "Does this mean it's a PolicyKit bug then?"

I was hoping you could tell us :)

"Maybe duping with #834494 is a good idea?"

That does appear to be the same issue, yes. Let's do it.

*** This bug has been marked as a duplicate of bug 834494 ***
Comment 29 Tim Lauridsen 2012-09-18 00:47:16 EDT
polkit 0.106 has a new way of defining rules

http://www.freedesktop.org/software/polkit/docs/master/polkit.8.html

The default rule in /etc/polkit-1/rules.d/50-default.rules 

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

I have tryed to change it to 

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

Then it works if the user is not member of wheel, but if the user is member of wheel, then you have select between root or the user in the authentication dialog and that is not to good for a usability point of view.

downgrading polkit will solve all issues, but i am sure that davidz can fix it, if he has the time :)

Note You need to log in before you can comment on or make changes to this bug.