Bug 638344
| Summary: | gpk-application is not requesting authorization | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | John Drinkwater <john> | ||||
| Component: | PackageKit | Assignee: | Richard Hughes <rhughes> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 14 | CC: | andy, conlinpg, iusers, james, jonathan, ken.tanzer, paul, rhughes, sergio, simfake.mapping, smparrish, vicsperry, zoinkle_burp | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-08-16 19:56:01 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
John Drinkwater
2010-09-28 19:48:19 UTC
The same problem in Fedora 12. After I upgrade my Fedora 11 to 12, I cannot use VNC to 'Add / Remove Software' using "Package Manager for GNOME" (gpk-application 2.28.3). The problem does not exists when I was using Fedora 11. Fedora 12 Version-Release: gpk-application 2.28.3 How to re-produce: 1. System -> Administration -> Add/Remove Software 2. Check some packages to install 3. Click Apply 4. Authorization Failed - Failed to obtain authentication. Expected result: Prompted enter root's password to continue. I have just found the same problem running over VNC on Fedora 14 Authorisation fails with no prompt to be able to provide it. (I tried this because on an ASUS Eee PC with 800x480 screen, Gnome Package Kit is unusable - Apply button is unreachable except by using alt-a, or sometimes being able to move the window up with the title bar off the screen using alt-m, uparrow, enter) I use yum most of the time anyway, but the package kit can be useful for browsing. Fedora 14 Version-Release: gnome-packagekit-2.32.0-2.fc14.i686 On my one (Fedora 14, x86_64, gpk-application 2.32.0), when attempting to add software, an authorisation request pop-up appeared once, but appeared frozen. I was unable to authorise or cancel, and had to click on the X to get rid of it, at which point a different "authorisation failed" pop-up appeared. On subsequent attempts, something strange seems to happen where the authorisation request pop-up "strobes" in rapid succession before the "authorisation failed" appears. I have this on Fedora 14 too. I'll look to see if there is a Fedora 14 bug report for it, and open one if not. It also seems to be the same as bug 546640 from Fedora 12. I clean-installed FC13 in September 2010 and got around to configuring the machine in Nov 2010. As soon as I brought up the VNC server and began to use it to manage my FC13 machine from a RealVNC client running on Windows 7, I began having this problem. When I try to run any root-required application from a pull-down menu, the system does not pop up the dialog requesting root password and instead, fails authorization as described in this thread. It doesn't matter what the application is; none of them work if they require root access. If I plug in a physical screen and keyboard to the FC13 machine, the authorization dialog works as expected. Normally, however, my machine does not have a physical screen and keyboard. VNC is my preferred access method. For now, I am getting around this by starting apps from the command line as root, but it would be nice to have the pull-downs working again. In Dec 2010, I upgraded to FC14, and this problem persists. Hi. I just hit this problem today with Fedora 14. I see this bug is 6 months old, with no comments/responses except from us users. Is there any likelihood of anyone working on this, even at least to figure out what the problem is? Also, it seems like the bug should be bumped to F14 so it doesn't get closed. Thanks. Ken, it appears vnc doesn't create the required session to allow policykit to work. The vnc developers don't see this as a bug, and so there's not much I can do to fix this. The reason for the failure is that the session component is asking for auth on a "non-active" session, which means that the action is disallowed for security reasons. You can easily change the defaults for the packagekit policykit actions to work without the active console, but I'm not sure it's completely safe to enable by default, and certainly not a great user experience. Same as original posters problem, except in fedora 15 alpha (after manually updating via yum as well.) Installed using the xfce live cd (if that is relevant). This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. 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 '13'. 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 13'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 13 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 Problem is reproducible in Fedora 14. Can someone please update the version on this bug.
Identical problem occurs with System -> Administration -> Software Update.
I suspect it's an SELinux permissions problem. Running gpk-update-viewer generates the following log messages:
gpk-update-viewertype=AVC msg=audit(1307037980.353:26829): avc: denied { connectto } for pid=2726 comm="gpk-update-view" path="/var/run/nscd/socket" scontext=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=unix_stream_socket
type=SYSCALL msg=audit(1307037980.353:26829): arch=40000003 syscall=102 success=yes exit=0 a0=3 a1=bffa7a34 a2=f79ff4 a3=bffa7a50 items=0 ppid=1 pid=2726 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="gpk-update-view" exe="/usr/bin/gpk-update-viewer" subj=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1307037980.363:26830): avc: denied { open } for pid=2726 comm="gpk-update-view" name="database" dev=dm-0 ino=927289 scontext=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xdm_var_run_t:s0 tclass=file
type=SYSCALL msg=audit(1307037980.363:26830): arch=40000003 syscall=5 success=yes exit=4 a0=bffa9e5b a1=0 a2=1b6 a3=d44832 items=0 ppid=1 pid=2726 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="gpk-update-view" exe="/usr/bin/gpk-update-viewer" subj=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1307037980.410:26831): avc: denied { setattr } for pid=2726 comm="gpk-update-view" name="orbit-andy" dev=dm-0 ino=927288 scontext=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=dir
type=SYSCALL msg=audit(1307037980.410:26831): arch=40000003 syscall=30 success=yes exit=0 a0=8e95668 a1=bffa78c8 a2=2a81784 a3=8e95668 items=0 ppid=1 pid=2726 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="gpk-update-view" exe="/usr/bin/gpk-update-viewer" subj=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1307037980.412:26832): avc: denied { write } for pid=2726 comm="gpk-update-view" name="orbit-andy" dev=dm-0 ino=927288 scontext=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=dir
type=AVC msg=audit(1307037980.412:26832): avc: denied { add_name } for pid=2726 comm="gpk-update-view" name="linc-aa6-0-7c7a3f4664e01" scontext=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=dir
type=AVC msg=audit(1307037980.412:26832): avc: denied { create } for pid=2726 comm="gpk-update-view" name="linc-aa6-0-7c7a3f4664e01" scontext=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1307037980.412:26832): arch=40000003 syscall=102 success=yes exit=0 a0=2 a1=bffa7770 a2=2a81784 a3=10 items=0 ppid=1 pid=2726 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="gpk-update-view" exe="/usr/bin/gpk-update-viewer" subj=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1307037980.453:26833): avc: denied { open } for pid=2726 comm="gpk-update-view" name="machine-id" dev=dm-0 ino=121 scontext=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_dbusd_var_lib_t:s0 tclass=file
type=SYSCALL msg=audit(1307037980.453:26833): arch=40000003 syscall=5 success=yes exit=11 a0=5e350e a1=0 a2=f79ff4 a3=bffa6758 items=0 ppid=1 pid=2726 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="gpk-update-view" exe="/usr/bin/gpk-update-viewer" subj=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1307037980.454:26834): avc: denied { setattr } for pid=2726 comm="gpk-update-view" name="bus" dev=dm-2 ino=57413 scontext=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:config_home_t:s0 tclass=dir
type=SYSCALL msg=audit(1307037980.454:26834): arch=40000003 syscall=15 success=yes exit=0 a0=8ece578 a1=1c0 a2=911e1c a3=8ee0e18 items=0 ppid=1 pid=2726 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="gpk-update-view" exe="/usr/bin/gpk-update-viewer" subj=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1307038452.488:26859): avc: denied { remove_name } for pid=2726 comm="gpk-update-view" name="linc-aa6-0-7c7a3f4664e01" dev=dm-0 ino=918262 scontext=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=dir
type=AVC msg=audit(1307038452.488:26859): avc: denied { unlink } for pid=2726 comm="gpk-update-view" name="linc-aa6-0-7c7a3f4664e01" dev=dm-0 ino=918262 scontext=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1307038452.488:26859): arch=40000003 syscall=10 success=yes exit=0 a0=8e9d890 a1=f7b3a8 a2=d4027c a3=10 items=0 ppid=1 pid=2726 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="gpk-update-view" exe="/usr/bin/gpk-update-viewer" subj=unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 key=(null)
Updated. For some reason I didn't get your comment in an email, hm.. Same in FC15. I believe the root cause has to do with polkit-gnome-authentication-agent-1 being unable to start *when a desktop environment other than the default at install* is in use. I started out with Gnome3, but am now using Gnome Classic with Compiz. Many of the posts I have read regarding this issue seem to have the same aspect. Authentication Agent is selected in the "Startup Programs" tab of the gnome-session-properties panel, but is not running. When I attempt to start it manually via /usr/libexec/polkit-gnome-authentication-agent-1, I get the message: (polkit-gnome-authentication-agent-1:23011): polkit-gnome-1-WARNING **: Unable to determine the session we are in: GDBus.Error:org.freedesktop.ConsoleKit.Manager.GeneralError: Unable to lookup session information for process '23011' (Corrections to comment #12, please ignore comment #12) Same in FC15. I believe the root cause has to do with polkit-gnome-authentication-agent-1 being unable to start *when a desktop environment other than the default at install* is in use. I started out with Gnome3, but am now using Gnome Classic with Compiz. Perhaps most relevantly, if I switch back to Gnome3 packagekit prompts for authentication and installs packages as expected. Authentication Agent is selected in the "Startup Programs" tab of the gnome-session-properties panel, but is not running. When I attempt to start it manually via: $ sudo /usr/libexec/polkit-gnome-authentication-agent-1, I get the message: (polkit-gnome-authentication-agent-1:23011): polkit-gnome-1-WARNING **: Unable to determine the session we are in: GDBus.Error:org.freedesktop.ConsoleKit.Manager.GeneralError: Unable to lookup session information for process '23011' When I attempt to start it manually via: $ su # /usr/libexec/polkit-gnome-authentication-agent-1, I get the message: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Terminated Also seen in F16, 0.6.20-1 series. Created attachment 546255 [details]
Output from running gpk-application -v
Attached output (captured with script) of running gpk-application from gnome-packagekit-3.2.1-1.fc16.x86_64, in a session where I tried to install a few packages from the Graphics group. Add/Remove Software failed to prompt for a password, and stopped at "authorisation failed".
Normal service resumed after logging out and back in.
Hi, I think this 2 bugs may be related https://bugzilla.redhat.com/show_bug.cgi?id=573499 https://bugzilla.redhat.com/show_bug.cgi?id=546640 so, first question, are you running gpk-application in vnc or kvm ? running ck-list-sessions, what you got ? ck-list-sessions, I just test it all thing working in my kde , if I run a vncserver under vnc , I got "You have failed to provide correct authentication. Please check any passwords or account settings." See ck-list-sessions Session4: unix-user = '500' realname = 'Sérgio Basto' seat = 'Seat4' session-type = '' active = FALSE x11-display = ':1' x11-display-device = '' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2012-05-02T21:38:39.311155Z' login-session-id = '4294967295' Session2: unix-user = '500' realname = 'Sérgio Basto' seat = 'Seat1' session-type = '' active = TRUE x11-display = ':0' x11-display-device = '/dev/tty1' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2012-05-01T21:02:00.160628Z' login-session-id = '4294967295' with active = FALSE , auth doesn't work (In reply to comment #10) I believe that my earlier comments actually were for a different (but similar-appearing) bug. The symptoms that I was reporting were not related to desktop or session environments, and that problem went away with a subsequent update of the SELinux policy files. So please ignore comment #10; it's not germane to the bug being reported here. This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached 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, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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 |