Bug 546640
| Summary: | Persistent creation of "Authorization Failed" dialogue boxes when running gnome via vnc | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jonathan Underwood <jonathan.underwood> | ||||
| Component: | PackageKit | Assignee: | Richard Hughes <richard> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 12 | CC: | abuse, bryan, felixbellaby, henry.barrowclough, jason-bz, raman_arora, redhat, redhat, rhughes, richard, sergio, smparrish, thomas, xcingix | ||||
| Target Milestone: | --- | Keywords: | Triaged | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2010-12-04 01:48:08 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: |
|
||||||
Created attachment 377742 [details]
Screenshot showing dialogue box
So, my hunch that this has something to do with ConsoleKit is probably on the right lines - in a terminal in the vnc session: $ ck-list-sessions Session1: unix-user = '42' realname = '(null)' seat = 'Seat1' session-type = 'LoginWindow' active = TRUE x11-display = ':0' x11-display-device = '/dev/tty1' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2009-12-11T15:55:49.492276Z' login-session-id = '4294967295' idle-since-hint = '2009-12-11T16:00:47.513966Z' Session3: unix-user = '500' realname = 'Jonathan G. Underwood' seat = 'Seat3' session-type = '' active = FALSE x11-display = '127.0.0.1:1' x11-display-device = '' display-device = '' remote-host-name = '127.0.0.1' is-local = FALSE on-since = '2009-12-11T16:14:10.933731Z' login-session-id = '3' So perhaps there's three bugs here: 1) vncserver doesn't properly register the session with consolekit? 2) g-p-m isn't turning off when running in such a session 3) g-p-m is giving (persistent) error boxes which aren't very helpful. (In reply to comment #2) > So perhaps there's three bugs here: > 1) vncserver doesn't properly register the session with consolekit? A VNC session shouldn't register itself as a local session. > 2) g-p-k isn't turning off when running in such a session You probably just need to disable the desktop file. > 3) g-p-k is giving (persistent) error boxes which aren't very helpful. Sure, we could certainly do better in this regard. Patches welcome. (In reply to comment #3) > (In reply to comment #2) > > So perhaps there's three bugs here: > > 1) vncserver doesn't properly register the session with consolekit? > > A VNC session shouldn't register itself as a local session. > OK - so I think you're saying that the observed behaviour is as expected here? > > 2) g-p-k isn't turning off when running in such a session > > You probably just need to disable the desktop file. Not sure I understand what you say here. The user really shouldn't need to know how to "disable the desktop file", g-p-k should surely just degrade gracefully for a non local session and not attempt to run? > > > 3) g-p-k is giving (persistent) error boxes which aren't very helpful. > > Sure, we could certainly do better in this regard. Patches welcome. OK, I'll dig a bit more, but having zero familiarity with the g-p-k codebase, it'll take a while. This bug has been triaged Steven M. Parrish KDE & Packagekit Triager Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers I am seeing the exact same error dialog constantly popup, but under different circumstances. I am on an upgraded Fedora system (11->12) and running on a normal desktop with local dual monitors, not through vnc. The error dialog box appears every few hours, not minutes, and sometimes comes in pairs, but not always. To make it worse, compiz will always crash if the mouse it placed over the untitled window in the task bar (separate bug #542804 though). Is there something wring with my login session since I did an upgrade instead of a fresh install? A possibly related symptom is that I do not get the halt and reboot buttons when I try to shutdown or reboot from the gnome menu. ~Jason I m using FC12 and hitting the same issue. It gets really annoying at times as there are multiple 'dialogue box' popping up every now and then. Is there a work around ? ie a process that we can kill to avoid this ? Can we increase the priority of this issue to get this fixed / patched. Yes, please increase the priority of this bug. It's very annoying. Also, it would be helpful if someone posted an instruction for a workaround. How do I "disable the desktop file"? What file is that? System -> Preferences -> Startup Applications Untick PackageKit Update Applet. Restart your vnc server. Note that you will no longer get an update icon in the notification panel when updates are available. Further to the comment that the problem can appear with dual monitors as well as vnc, I have also seen it when switching between desktop users on a single monitor setup. PackageKit runs with one instance of gpk-update-icon for EACH user running a gnome-session. However, each of these gpk-update-icon processes probably relies on another process to handle the actual search for updates. This second process (possibly part of yum) is probably unique and running as the first logged in user. If so, then the second gpk-update-icon process may be assuming that it can talk to the other process (e.g using dbus) and is then finding that this is impossible because it is using the wrong authorisation tokens. However, the gpk-update-icon developer is seriously culpable for deciding to pop up a dialog box that reports an error without providing ANY details on how or where it arose beyond "authorisation failed". The gnome libraries include facilities for reporting errors that automatically provide detailed information on where the error arose. USE THEM. (In reply to comment #10) > PackageKit runs with one instance of gpk-update-icon for EACH user running a > gnome-session. Correct. > However, each of these gpk-update-icon processes probably relies > on another process to handle the actual search for updates. This second process > (possibly part of yum) is probably unique and running as the first logged in > user. Incorrect, packagekitd runs as root, in the system context. > If so, then the second gpk-update-icon process may be assuming that it > can talk to the other process (e.g using dbus) and is then finding that this is > impossible because it is using the wrong authorisation tokens. Err, no. You don't need "authorisation tokens" to do a request to a dbus server. > However, the gpk-update-icon developer is seriously culpable for deciding to > pop up a dialog box that reports an error without providing ANY details on how > or where it arose beyond "authorisation failed". That's all the information we get from PolicyKit. Maybe we should hide the authorization UI, there's not really much the user can do at the failed stage. > The gnome libraries include > facilities for reporting errors that automatically provide detailed information > on where the error arose. USE THEM. I've been a GNOME developer for nearly 8 years, maintaining 3 upstream GNOME projects all in the official desktop set, and I have no idea what you mean by "gnome libraries that automatically provide detailed information on where the error arose". Doesn't make much sense to me. Richard. I was only speculating on the possible meaning of the "authorisation failed" message message sent from policykitd to the gpk-update-icon. If it has nothing to do with the gpk-update-icon failing to communicate with the policykitd then what does it mean? I worked on the development of the gnome libraries before gnome 1.0 was released. We discussed UI design till we were blue in the face and agreed that modal dialog boxes were generally to be avoided. They sometimes help debugging code, but you need a damn good reason to leave them in the finished product. If the message that they produce means nothing to the end user and there is nothing that they can usefully do in response then dialog box generating code should be removed. I was thinking of the error reporting mechanisms built into glib (i.e. glib/gmessages.h). These are intended to provide the developer/debugger with a much better way of tracking what is going on than a dialog box can provide. In particular, they make it clear which process is generating the message and where it is coming from in the code. A modal dialog box that says "authorisation failed" without even giving the name of the application throwing up the dialog is a long way from providing that information. This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 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. im also effected by this bug on fedora 14 |
Description of problem: I frequently access one of my boxes remotely, running a gnome session inside vnc. I constantly get dialogue boxes popping up with the message "Authorization Failed" in them.They seem to originate from packagekit, judging by the icon in the titlebar - see screenshot attached. They appear every few minutes, in pairs i.e. clicking close once immediately brings up an identical box. Clicking close again gets rid of the second one. A few minutes later a new box appears. Repeat ad-nauseum. There are a number of problems here: 1) I shouldn't really be seeing these boxes in the first place - I am not sure what the underlying bug is. Is this gnome session not getting the correct policykit privs or something? 2) The boxes really could be a lot more helpful by explaining what program they originate from, what authorization it was looking for and why etc. 3) The dialogue box should have a title in the title bar, and shouldn't appear as "untitled window" in the task bar button at the bottom. In case it is relevant, the way I have this gnome/vnc setup is: I have a xinetd service defined: $ cat /etc/xinetd.d/vnc service vnc1280x1024 { disable = no socket_type = stream protocol = tcp wait = no user = nobody group = tty server = /usr/bin/Xvnc server_args = -inetd -query 127.0.0.1 -once -SecurityTypes None -geometry 1280x1024 -depth 16 } and a corresponding entry in /etc/services: vnc1280x1024 6900/tcp # Local vnc server I then connect to port 6900 with a vnc client, which brings up GDM in a vnc session from which I log into Gnome. Version-Release number of selected component (if applicable): PackageKit-yum-0.5.4-0.4.20091029git.fc12.x86_64 PackageKit-gtk-module-0.5.4-0.4.20091029git.fc12.x86_64 PackageKit-0.5.4-0.4.20091029git.fc12.x86_64 PackageKit-command-not-found-0.5.4-0.4.20091029git.fc12.x86_64 PackageKit-yum-plugin-0.5.4-0.4.20091029git.fc12.x86_64 PackageKit-device-rebind-0.5.4-0.4.20091029git.fc12.x86_64 PackageKit-gstreamer-plugin-0.5.4-0.4.20091029git.fc12.x86_64 PackageKit-glib-0.5.4-0.4.20091029git.fc12.x86_64 ConsoleKit-libs-0.4.1-1.fc12.x86_64 ConsoleKit-x11-0.4.1-1.fc12.x86_64 ConsoleKit-0.4.1-1.fc12.x86_64 Expected results: PackageKit to function normally in the Gnome session, or ONCE to pop up a dialogue box saying that for $reason PackageKit can't operate in the current session and has been disabled.