Bug 439532 - System update from non privledged account
System update from non privledged account
Product: Fedora
Classification: Fedora
Component: gnome-packagekit (Show other bugs)
i686 Linux
low Severity high
: ---
: ---
Assigned To: Robin Norwood
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-03-28 17:54 EDT by Leslie Satenstein
Modified: 2008-03-28 21:29 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-28 20:26:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Leslie Satenstein 2008-03-28 17:54:12 EDT
Description of problem:

Let me write some activities that I did, and then YOU decide if I am dreaming or
stupid about reporting this SECURITY PROBLEM.

1) Power on computer and boot desktop system. 
2) Log onto root, 
3) Initiate software update
4) Copy xorg.conf to desktop in preparation of collecting data for response to
another bug
5) Mouse locks up, with strange cursor symbol during update.
6) I tried to get out of it. In the meantime, software updates are being downloaded.
7) I did the obvious CTL-ALT-BACKSPACE, Logon Prompt appeared.
9) Logged onto insecure account -- regular user (my account)
10) Clicked on icon (brown star) to initiate a system update.

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

Mother Board  intel d945gnt. RAM 3.5gigs, Hard disk 330gig Video -- Integrated 
Driver -- Intel  

How reproducible:

This occurred once. I am not dreaming. Does it mean that if I start a large
update (many files), that I can logout (via ctl-alt-backspace) and I can log in
as a regular user and start the update, without having to present a password?

Steps to Reproduce:
1. Read Introduction (above)
Actual results:

System was updated

Expected results:

I should have been prompted for root password.

Additional info:

The gnome "Star" that shows I am running with root privileges was not presented.
Selinux is in permissive mode, as some system updates would not take place

I am happy it is Rawhide, and not Fedora8. I will try the same with 8, now that
my curiosity is raised.
Comment 1 Richard Hughes 2008-03-28 20:26:59 EDT
Leslie, because packagekitd is a system service, it continues to run when you
log out or fast user switch. This is a good thing, as it prevents nuking your
rpmdb just by doing ctrl-alt-backspace.

When you logged in to your user account, the update system was still running in
the background.

What you probably want to try to convince youself, is wait until the next lot of
rawhide updates. In your _user_ session, try to update the system and you will
be prompted for the root password. The fact that you authorised the action in
one session means that it's valid in all local sessions. Checkout
polkit-gnome-authorization and you'll see the number and type of permissions you
can set.

I don't think the mouse locking up is due to the system update, if the packages
are just being downloaded then there is no action on the filesystem - we can
just blame Xorg or the kernel for that.


Comment 2 Leslie Satenstein 2008-03-28 21:20:07 EDT
Hi Richard.
What started all the research in this area was some other problems with X11.
I cannot force X to recreate the xorg.conf, and it causes a loss of mouse
left-or-right button click.

But, here is a question that you may want to answer off-line..
If in userid1 I start the update and then ctl-alt-backspace and log as user2,
with the update/download still going, will I have system priviledges in user2
because the x minutes given user1 did not elapse.  It shouldn't, but this is
newer code, and to support your reply, in Fedora8, there was no problem of this
Comment 3 Richard Hughes 2008-03-28 21:29:06 EDT
>will I have system priviledges in user2 because the x minutes given user1 did
not elapse

Nope, you don't get system priviledges when you do the update, you only give
permission to the dameon to do one sort of action. In this way the policy is
fine-grained, and is not exploitable.

You might want to checkout http://www.packagekit.org and
as it explains things in more detail.

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