Description of problem:
PackageKit currently has hard-coded that remote execution (eg via ssh-tunneled VNC or NX) is not possible. This means that the only ways to update systems headlessly are either:
.to open up X11 security holes or
.to use command line updating and forego all the benefits of PackageKit
Both cause real problems for admins.

Version-Release number of selected component (if applicable): all current versions
How reproducible: Always

Steps to Reproduce:
1. Run PackageKit from a remote terminal
  
Actual results:
Refuses to run, and no mechanism to permit PolicyKit to override this

Expected results:
Packagekit allows policy to permit remote execution

Additional info:
I may be missing the point, but this hard-coding of no remote use seems to cut against the whole philosophy of PolicyKit: that the admin should be able to configure system security policies to suit the particular installation, because system developers can't  anticipate all the relevant combinations of circumstances. It seems in this case that PolicyKit and the policy tool provide the mechanisms necessary for admins to set such policies, but PackageKit ignores them - see lines in gpk-common.c folowing
        /* we are not local */
        ret = egg_console_kit_is_local (ck);
        if (!ret) {

I can understand why this test has been included; without it, the default PackageKit operations would be available to potentially unchecked and malicious remote users, unless re-configured by admins. This is probably not desirable. However it seems to me that there is a better way, more in harmony with PolicyKit philosophy. That is, to add an additional PolicyKit action, namely "Run PackageKit". The default settings for this action would be that it was only allowed from the Console (thus the egg_console_kit_is_local call above could be replaced by a call to PolicyKit, and would have the same result under the default settings). However it would allow admins to permit remote use of PackageKit under whatever circumstances they deemed appropriate, by changing from the defaults. 

I would like to add that, if the current version hits RHEL, the anguish of sysadmins will be heard from a long way off. Headless administration may not be too common among Fedora users, but it will be a huge issue for RHEL.