Red Hat Bugzilla – Bug 439532
System update from non privledged account
Last modified: 2008-03-28 21:29:06 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
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.
11) NO PASSWORD PROMPT WAS ISSUED. IT JUST WENT INTO THE UPDATE MODE. AND YES,
UPDATES COMPLETED COMPLETELY.
IS THIS A NEW FEATURE?
Version-Release number of selected component (if applicable):
Mother Board intel d945gnt. RAM 3.5gigs, Hard disk 330gig Video -- Integrated
Driver -- Intel
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)
System was updated
I should have been prompted for root password.
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.
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
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
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.
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
>will I have system priviledges in user2 because the x minutes given user1 did
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.