Bug 546640 - Persistent creation of "Authorization Failed" dialogue boxes when running gnome via vnc
Summary: Persistent creation of "Authorization Failed" dialogue boxes when running gno...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: PackageKit
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-12-11 15:05 UTC by Jonathan Underwood
Modified: 2012-05-02 20:14 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-12-04 01:48:08 UTC


Attachments (Terms of Use)
Screenshot showing dialogue box (253.95 KB, image/png)
2009-12-11 15:10 UTC, Jonathan Underwood
no flags Details

Description Jonathan Underwood 2009-12-11 15:05:25 UTC
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.

Comment 1 Jonathan Underwood 2009-12-11 15:10:57 UTC
Created attachment 377742 [details]
Screenshot showing dialogue box

Comment 2 Jonathan Underwood 2009-12-11 16:19:27 UTC
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.

Comment 3 Richard Hughes 2009-12-12 19:41:56 UTC
(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.

Comment 4 Jonathan Underwood 2009-12-12 19:59:01 UTC
(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.

Comment 5 Steven M. Parrish 2009-12-22 14:27:44 UTC
This bug has been triaged

Steven M. Parrish
KDE & Packagekit Triager 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 6 Jason A. Smith 2010-01-06 11:12:26 UTC
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

Comment 7 RdA 2010-04-15 12:39:32 UTC
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.

Comment 8 Thomas Hallgren 2010-04-28 09:22:40 UTC
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?

Comment 9 Henry Barrowclough 2010-04-28 12:02:28 UTC
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.

Comment 10 Felix Bellaby 2010-07-16 10:21:37 UTC
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.

Comment 11 Richard Hughes 2010-09-01 06:56:49 UTC
(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.

Comment 12 Felix Bellaby 2010-09-10 17:15:43 UTC
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.

Comment 13 Bug Zapper 2010-11-04 03:36:28 UTC
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

Comment 14 Bug Zapper 2010-12-04 01:48:08 UTC
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.

Comment 15 Danny Michel 2011-05-20 13:28:25 UTC
im also effected by this bug on fedora 14


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