Bug 1094120 - Packagekit polkit policy is desktop centric, prevents server usage
Summary: Packagekit polkit policy is desktop centric, prevents server usage
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: PackageKit
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1094121
TreeView+ depends on / blocked
 
Reported: 2014-05-05 06:22 UTC by Stef Walter
Modified: 2014-05-08 09:33 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-05-08 09:33:33 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
FreeDesktop.org 78276 None None None Never

Description Stef Walter 2014-05-05 06:22:49 UTC
Description of problem:

The Packagekit polkit policy is completely desktop-centric and expects that the user (admin or not) is logged in an active local session (ie: a seat in logind parlance, with a monitor and keyboard).

This prevents use of PackageKit when logged in via ssh (and using pkttyagent as your polkit agent) or via Cockpit.

The <allow_any> tag in polkit policy applies to non-local sessions. It should be set to something other than 'no' unless the action directly affects hardware of the login seat.

Version-Release number of selected component (if applicable):

PackageKit-0.8.17-1.fc20.x86_64

How reproducible:

Every time.

Comment 1 Stef Walter 2014-05-05 06:23:06 UTC
Upstream patch posted.

Comment 2 Rex Dieter 2014-05-05 13:38:19 UTC
The policy as currently implemented was a result of FESCo policy,
https://fedoraproject.org/wiki/Privilege_escalation_policy 
which includes:

in short, admin auth is required for:

* Add, remove, or downgrade any system-wide application or shared resource (packaged or otherwise), with the exception that for installing Fedora-signed packages from administrator-configured repositories, the requirement to ask for a password is waived for members of the wheel group who are local and active.

* Shutdown or reboot the system (unless they are the only user logged in, and they are logged in locally)


It seems to me that your proposal is asking to reverse (at least) these 2 items for non-local logins.   Is that accurate?  (or am I misunderstanding?)

If so, I would recommend you reach out to FESCo to consider your use-case, to modify the Privilege_escalation_policy accordingly.  Once that is done, then PackageKit can be modified to comply with the new policy.

Comment 3 Stef Walter 2014-05-05 13:46:24 UTC
(In reply to Rex Dieter from comment #2)
> The policy as currently implemented was a result of FESCo policy,
> https://fedoraproject.org/wiki/Privilege_escalation_policy 
> which includes:
> 
> in short, admin auth is required for:
> 
> * Add, remove, or downgrade any system-wide application or shared resource
> (packaged or otherwise), with the exception that for installing
> Fedora-signed packages from administrator-configured repositories, the
> requirement to ask for a password is waived for members of the wheel group
> who are local and active.
> 
> * Shutdown or reboot the system (unless they are the only user logged in,
> and they are logged in locally)
> 
> 
> It seems to me that your proposal is asking to reverse (at least) these 2
> items for non-local logins.   Is that accurate?  (or am I misunderstanding?)

Could you point out which ones?

I'm not at all waiving the requirement to ask for a password. By using 'admin_auth' I'm only allowing escalation when reauthorization is provided.

Currently PackageKit flat out refuses to talk to users logged in via ssh (for the various actions that I've patched). After the changes it'll (via polkit) ask them to reauthorize before performing the task in question.

I don't think this requires a change in FESCO policy.

Comment 4 Rex Dieter 2014-05-05 14:08:16 UTC
OK, thanks for the clarification.  I would agree no change in FESCo policy is required to implement this.

Comment 5 Richard Hughes 2014-05-08 09:33:33 UTC
Fixed upstream. Thanks.


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