From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5) Gecko/2008043010 Fedora/3.0-0.60.beta5.fc9 Firefox/3.0b5 Description of problem: I am not able to update the system [ Fedora 9 [x86_64]]. When i go to Menu System ▸ Administration ▸ Update System. It give me an error as "the error was : org.freedesktop.packagekit.update-system auth_admin_keep_always" Second when i select individual updates and click on " Apply Updates " i cannot update & nothing happens [there is no error message]. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Go to Menu System ▸ Administration ▸ Update System. 2. Click on Update System or Click on Review and select individual update and click on Update Now 3. It give me an error as "the error was : org.freedesktop.packagekit.update-system auth_admin_keep_always" Actual Results: Expected Results: Additional info:
Created attachment 305912 [details] Error messsage
Created attachment 305913 [details] Error messsage
I have attached screen shot kindly look into this. I am not that tech so i had to use screen shot and i love fedora. I have been using Fedora 7 for 9 months so i think i did a mistake by updating to Fedora 9
Please see http://fedoraproject.org/wiki/PackageKitFaq -- you really shouldn't be running as the root user!
gnome-packagekit-0.1.12-14.20080516.fc9 has been submitted as an update for Fedora 9
> - Prevent the GTK GUI tools from being run as root as PolicyKit > authentication will not work Huh? Then surely the real bug is there. Root should be allowed to do everything, the PolicyKit authentication should always succeed for root. And in fact it does for HAL (which is why the KDE hack which uses kdesu to dbus-send to HAL as root if we got PermissionDeniedByPolicy when sending the request from our regular user http://cvs.fedoraproject.org/viewcvs/rpms/kdelibs/F-9/kdelibs-4.0.2-policykit-workaround.patch?rev=1.1&view=markup resp. http://cvs.fedoraproject.org/viewcvs/rpms/kdebase3/F-9/kdebase-3.5.9-userdiskmount.patch?rev=1.2&view=markup works). > and using GTK in this way so may be insecure. If you're logged in as root to perform multiple administration tasks, this is the least of your worries, and it's ridiculous that an _administration tool_ of all things refuses to run as root. Besides, I don't see how attacks like LD_LIBRARY_PATH hacks or the like (which are why GTK+ refuses to run setuid) would affect entire sessions running as root, you have to be root already to inject such nasties into the session!
Oh and also the user should NOT be annoyed with password prompts if he/she is already logged in as root.
Well, the real bug is that we allow users to login as root from GDM. GTK+ or QT applications shouldn't be run as root.
IMHO the real bug is that you assume that people who have more than one administration task to do want to reenter their root password every few seconds. (And I'm aware of kludges like consolehelper's password caching, but those are only partial solutions and aren't necessarily less of a security risk than just being logged in as root in the first place: if your user can do root tasks without entering a root password, how is it more secure than just being root?) I know PolicyKit should help solving this problem in the long term. The thing is, we're really not there yet. As for Qt applications not being supposed to run as root, what do you think kdesu does? That's used in many places in KDE.
Oh, and you can screw up the system pretty badly by removing e.g. the glibc package, so even giving your user access only to PackageKit (and nothing else) without a password prompt through PolicyKit means your user is no longer less of a security risk than root. Now you're going to say the "without a password prompt" part is the problem, but that's exactly my point: users don't want to enter a password all day long. They will always want things set up in a way which is a "security risk". You cannot eliminate that risk without pissing them off.
Hey All, Thanks for looking into the issue. Before i looked into the ticket i logged in as normal user on my system and i am able to update the system. But the concern is if this was intended [ root not able to update the system ] why there was no message give by the tool stating " cannot update system due to security reasons "
That's exactly what the update which has been submitted is fixing.
I don't think there should be any automatism in PolicyKit for root to be allowed to do everything. But as long as root is allowed to log in, installing updates as root should certainly work (after obtaining the necessary polkit authorizations)
FWIW, I also think hardcoding "root can do everything" in PolicyKit is wrong, but IMHO the default policy should be for root not to be prompted for a password, and root should definitely not get denied authentication altogether.
gnome-packagekit-0.1.12-14.20080516.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update gnome-packagekit'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-4141
I don't support gnome-packagkit tools being run as the root user as the programs have really not been audited or tested like the daemon has.
Looks like PolicyKit has been fixed: https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00742.html so can this arbitrary limitation please be removed now?
Or is that fix unrelated to this bug?
The patch in msg00742.html allows root to _read_ authorisations, not be automatically authorised through authentication. One does not imply the other. See http://www.duke.edu/~rob/kerberos/authvauth.html for more info.
It's actually trivial to fix this properly in PolicyKit. Attaching patch.
Created attachment 323469 [details] PolicyKit-0.8-allow-root.patch This trivial patch removes a completely unnecessary check from polkit-grant-helper, allowing root to authenticate through PolicyKit like any other user. This makes things like PackageKit (with KPackageKit - I know gnome-packagekit has an extra check against running it as root now, that check will also be unnecessary with this fix) just work as root. Whether to allow root to do certain actions without a password prompt is then just a policy decision, unrelated to this fix.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Still not fixed.
*** Bug 505767 has been marked as a duplicate of this bug. ***
*** Bug 507881 has been marked as a duplicate of this bug. ***
*** Bug 507937 has been marked as a duplicate of this bug. ***
I'll second applying any fix to PK to allow root access. I found this bug via this thread: https://fcp.surfsite.org/modules/newbb/viewtopic.php?topic_id=71871&forum=10&post_id=350216 My situation is that I'm setting up a RHEL/CENTOS 5.3 server which needs printers, but no local users (e.g. a printserver). Also I've allowed root to login via GDM. As it stands, root isn't allowed to complete the system-config-printer applet, and yet I have no other non-root users defined to execute this function with. As far as philosophy... I'll agree with both sides of the argument: #1-(Human) users should not run things as root, to avoid security issues #2-The OS should let root do 'anything' I don't that that #1 should be enforced by ignoring #2.
I personally do not think we should take the typical Microsoft mentality of "we should decide how people should use their PCs". Let's not be like Microsoft. If I want to run an application as root, just let me do it. I think I'm smart enough to know what I'm doing and I don't want my OS to start telling me what I shouldn't be doing. Next thing you know I wont even be able to edit my .bashrc file without being prompted by a dialog box telling me I shouldn't be editing this file!! Please people.
(In reply to comment #28) > I think I'm smart enough to know what I'm doing and I don't want my OS to > start telling me what I shouldn't be doing. Can you explain how to stop hijacking the session using gdb and GTK_MODULES? Dude, if I'm not smart enough to understand all the issues (and I wrote the code) then I doubt the ordinary user is doing to get the subtle nuances of ptrace. I'm not sure I agree with PolkicyKit hardcoding root to be refused (but that's not my call) but please be careful with throwaway remarks about security.
(In reply to comment #4) > Please see http://fedoraproject.org/wiki/PackageKitFaq -- you really shouldn't > be running as the root user! NO. In my case, I get the same error messages both for root AND a normal user. When trying to change the "Printout mode" to "Draft", both as root and as normal user, and get the same message: Unauthorized request (addPrinter) You are not authorized to carry out the requested action. (I didn't ask for add a printer!) This is amazing. Fedora always managees to break things that worked for years without problem. That's Fedora... The name should be changed to Bugdora. L.
*** Bug 508448 has been marked as a duplicate of this bug. ***
(In reply to comment #30) > (In reply to comment #4) > > Please see http://fedoraproject.org/wiki/PackageKitFaq -- you really shouldn't > > be running as the root user! > > NO. In my case, I get the same error messages both for root AND a normal user. > When trying to change the "Printout mode" to "Draft", both as root and as > normal user, and get the same message: > > Unauthorized request (addPrinter) > You are not authorized to carry out the requested action. > > (I didn't ask for add a printer!) The same IPP operation is used for adding a printer and for modifying it. If you are seeing the same failure as a non-root user, perhaps your password is longer than 32 characters and you are seeing bug #507633? system-config-printer users: 'yum remove cups-pk-helper' as a work-around to the PolicyKit 'root is denied' issue. This removes the PolicyKit support in system-config-printer.
(In reply to comment #32) > (In reply to comment #30) > > (In reply to comment #4) > > > Please see http://fedoraproject.org/wiki/PackageKitFaq -- you really shouldn't > > > be running as the root user! > > > > NO. In my case, I get the same error messages both for root AND a normal user. > > When trying to change the "Printout mode" to "Draft", both as root and as > > normal user, and get the same message: > > > > Unauthorized request (addPrinter) > > You are not authorized to carry out the requested action. > > > > (I didn't ask for add a printer!) > > The same IPP operation is used for adding a printer and for modifying it. I see. > If you are seeing the same failure as a non-root user, perhaps your password is > longer than 32 characters and you are seeing bug #507633? No, short password here. > system-config-printer users: 'yum remove cups-pk-helper' as a work-around to > the PolicyKit 'root is denied' issue. This removes the PolicyKit support in > system-config-printer. Your workaround worked. At least in one computer (in another, system-config-printer gets stuck). Thanks! L.
While this issue has been fixed in F11 by system-config-printer-1.1.8-1.fc11, it is again impossible to add a network printer when launched from the GNOME menu for current "rawhide" (Display Test Day live CD). After providing all required data, a final confirmation leads to an error message: "Unauthorized request (addPrinter) You are not authorized to carry out the requested action." However, when run by root from the shell, no problem occurs. Installed packages include - cups-pk-helper-0.0.4-2.fc12.i586 - system-config-printer-1.1.8-5.fc12.i586 Removing cups-pk-helper-0.0.4-2.fc12.i586 restores correct function of s-c-p.
Joachim: if you are seeing a problem when authenticating as a non-root user, please report a separate bug. This bug report is for PolicyKit denying operations requested by root.
Just spent a beautiful summer afternoon trying to figure why my f(*^ing printer stopped working and why the f(*& I was getting NameError in s-c-p when trying to fix it, the latter of which lead me here. More of my life again wasted because the we-know-better-than-you people had to protect the user from him/herself in yet another bulls^&* fashion, but breaks functional tools *again* in the process. You must be *so* proud of yourselves.
(In reply to comment #36) > Just spent a beautiful summer afternoon trying to figure why my f(*^ing printer > stopped working and why the f(*& I was getting NameError in s-c-p when trying > to fix it, the latter of which lead me here. More of my life again wasted > because the we-know-better-than-you people had to protect the user from > him/herself in yet another bulls^&* fashion, but breaks functional tools > *again* in the process. You must be *so* proud of yourselves. I've been using redhat since 4.1, and Fedora since 1. I installed recently Fedora 11 from scratch. Printing, sound, networking, SSH, KDE... didn't work properly. I still have many crashes in KDE. Ok KDE is complex, but printing and sound???? Fedora 11. My last redhat-related product. My next install will be Debian. A pity. L.
PolicyKit 1.0 fixes this.
Is there a particular reason this hasn't been pushed into F11 updates? I installed F11 clean and then move over all my configs from F10 to clear out the cruft. But there are some things that I cannot do (like install my printer) due to this bug (and it's companion that won't let me do it from an ordinary user account).
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.