Bug 218562 - Package Updater shouldn't require a root password to show you what updates are available.
Package Updater shouldn't require a root password to show you what updates ar...
Status: CLOSED DUPLICATE of bug 213879
Product: Fedora
Classification: Fedora
Component: pirut (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks: FC7Target
  Show dependency treegraph
 
Reported: 2006-12-05 20:21 EST by Rodd Clarkson
Modified: 2014-01-21 17:56 EST (History)
2 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Rodd Clarkson 2006-12-05 20:21:10 EST
Description of problem:

The package updater that appears in the Notification Area informs you that x
number of updates are avaiable, but you can't find out what these are without
having to enter the root password.

Users shouldn't have to enter the root password to see what updates are
avaiable.  IT seems that the package updater knows what needs to be updated, so
there shouldn't be any need to type a password in just so you can see what needs
updating.

For example, user without root access may be interested in seeing what updates
are available so they can nag their sysadmin about important updates, instead of
just nagging their sysadmin so they can see the updates.


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

yum-3.0.1-2.fc6
Comment 1 Jeremy Katz 2006-12-05 21:06:56 EST
That's the plan, just ran out of time for FC6 :)
Comment 2 Andre Robatino 2006-12-06 16:17:56 EST
  In the Summary line, "should" should be changed to "shouldn't".
Comment 3 Rodd Clarkson 2006-12-06 23:30:30 EST
Ah, yes.
Comment 4 Douglas Campbell 2006-12-18 12:54:05 EST
Why shouldn't this system configuration object require a password?  Why should a
nonprivileged user be able to, via back channels, interrogate versioning of the
software installed on target system? I would actaully advocate moving the
software updater from Applications menu to System/Administration menu, and
leaving the password in place.  Alternatively, as part of SELINUX security
profile, allow marking of pup as root-only.
Comment 5 Rodd Clarkson 2006-12-18 16:13:07 EST
(In reply to comment #4)
> Why shouldn't this system configuration object require a password?

I'm not advocating that the user be able to install the software, but if the
user is to be informed that updates are available, then they should be able to
easily see what updates are available.  It's not like they can't find out this
information elsewhere.

>  Why should a nonprivileged user be able to, via back channels, interrogate
> versioning of the software installed on target system?

Unless I'm missing something, the user already can do 'interogate versioning'. 
Grab a terminal and type in 'rpm -q <package ...>'

Are you advocating that we remove terminal access, allow with all the virtual
terminals so that the user can't be more aware of what's on the computer they use?

> I would actaully advocate moving the software updater from Applications menu
> to System/Administration menu, and leaving the password in place.

May as well get rid of the update alert in the Notification Area too.  After
all, even if the user can't find out what's being offered for update using the
desktop, it might alert them to the fact that updates are avaiable and go and
find the information somewhere else (even if it means browsing the ftp
repositories).

> Alternatively, as part of SELINUX security profile, allow marking of pup as
root-only.

Would this mean you'd need to be running your desktop as root to be alerted to
updates?  I didn't think that was 'best practice'.

Comment 6 Jeremy Katz 2007-09-11 15:08:27 EDT

*** This bug has been marked as a duplicate of 213879 ***

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