RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 584899 - PackageKit allows non-root users to install software updates
Summary: PackageKit allows non-root users to install software updates
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: PackageKit
Version: 6.0
Hardware: All
OS: Linux
low
high
Target Milestone: rc
: ---
Assignee: Richard Hughes
QA Contact: desktop-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-22 17:03 UTC by Phil Perry
Modified: 2010-11-11 15:23 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-11 15:23:58 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Phil Perry 2010-04-22 17:03:28 UTC
Description of problem:

Non-root users are able to install updated software packages without being prompted for root credentials.

Version-Release number of selected component (if applicable):
PackageKit-0.5.6-2.el6

How reproducible:
Always

Steps to Reproduce:
1. Install RHEL6beta1
2. System > Administration > Software Update
3.
  
Actual results:
Non-root users are able to update system software.

Expected results:
Root credentials would be required to update system software.

Additional info:
Do we really want to allow non-root users to install system updates by default.

Comment 1 Phil Perry 2010-04-22 17:06:09 UTC
Seems related to this bug in F12:

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

Comment 2 Alan Bartlett 2010-04-22 17:14:59 UTC
This is clearly a Fedora "feature" that must not be allowed in an Enterprise class OS.

I trust that this bug will be squashed, immediately.

Comment 3 Scott Robbins 2010-04-22 17:15:56 UTC
Confirmed.

If folks remember, this was really almost identical to 

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

which made slashdot and distrowatch.   While, as the developer says, there is a difference between updating already installed packages vs. installing previously uninstalled packages, this is simply unacceptable for many people (e.g., the last person to post in the Fedora bug that Ned mentions.)  

I don't believe that even Windows allows this

Comment 4 Phil Perry 2010-04-22 18:19:55 UTC
(In reply to comment #3)
> Confirmed.
> 
> If folks remember, this was really almost identical to 
> 
>  https://bugzilla.redhat.com/show_bug.cgi?id=534047
> 

I didn't read that bug in it's entirety, but one thing I'd like to point out that I didn't see mentioned is that this bug doesn't just apply to trusted Red Hat repositories, but applies to *all* (signed) repositories.

Given that an administrator might trust content from varying repositories to different extents (do you trust all your 3rd party repos to the same extent as you trust rhel/updates?), I'm not convinced I would want non-root users to be able to install updates by default that may potentially break things (*cough* ClamAV breaks every time it's updated!) and then not have the required privileges (or expertise) to fix what has broken.

IMHO ultimately this is a decision for the system administrator to make and the default policy should be one of caution as was previously the case. I just find it somewhat strange to see this "feature" in a release that also brings SELinux advancements allowing system administrators to further restrict users. It seems like pulling in two completely opposite directions.

Comment 6 RHEL Program Management 2010-04-22 20:13:14 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 12 Richard Hughes 2010-05-04 14:28:29 UTC
* Tue May 04 2010 Richard Hughes  <rhughes> - 0.5.8-3
- Use more secure defaults to only allow the root user to update the system.
- Resolves: #584899

Comment 14 Tomas Pelka 2010-05-10 10:13:49 UTC
Reproducer in description, expected behaviour: user should obtain pk password dialog window.

Giving qa_ack.

Comment 15 Tomas Pelka 2010-06-07 07:08:54 UTC
Expected behaviour verified on PackageKit-0.5.8-6.el6.

Comment 16 releng-rhel@redhat.com 2010-11-11 15:23:58 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.


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