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

(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?

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

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 ?

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.

With latest PackageKit I'm able to install packages on Gnome spin, auth agent popups correctly, password is accepted.

Information about how the F18 system is installed, is useful to reproduce the problem. (Updated from F17 or some TC release ?)

I have installed F18 Alpha TC4 (or something like that) and upgraded since then.

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.

# 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)

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.

(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

@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

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.

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.

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.

(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.

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'.

Kamil already filed such a firstboot bug, for reference, it's https://bugzilla.redhat.com/show_bug.cgi?id=856194 .

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?

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.

(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

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.

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

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.

(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?

(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 :)

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 ***

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 :)