Gnome PolicyKit + Keyring + dbus issues

My Gnome environment has a security issue affecting many other apps. The root of the problem is with the dbus => gnome-keyring interaction. Messages are:
From Dmesg:
Code:
polkitd(authority=local): Registered Authentication Agent for unix-session: /org/
freedesktop/ConsoleKit/Session1 (system bus name :1.15 [/usr/local/libexec/polkit-gnome-
authentication-agent-1], object path /org/gnome/PolicyKit1/AuthenticationAgent, locale )

gnome-keyring-daemon: couldn't allocate secure memory to keep passwords and or
keys from being written to the disk

dbus-daemon: [system] Rejected send message, 2 matched rules; type="method_call",
 sender=":1.39" (uid=xxx pid=1710 comm="nautilus ") interface="org.freedesktop.DBus.
Properties" member="GetAll" error name="(unset)" requested_reply=0 destination=":1.2" 
(uid=0 pid=1710 comm="/usr/local/sbin/console-kit-daemon --no-daemon "))

seahorse-daemon: init gpgme version 1.3.0
and in other places:
Code:
(polkit-gnome-authentication-agent-1:1722): polkit-gnome-1-WARNING **: Error 
enumerating temporary authorizations: GDBus.Error:org.freedesktop.PolicyKit1.
Error.Failed: Cannot determine session the caller is in
Code:
atk-bridge-WARNING **: AT_SPI_REGISTRY was not started at session startup.
(gnome-settings-daemon:1710): atk-bridge-WARNING **: IOR not set.
Supporting Evidence: Other apps complain in various ways when they are launched as root from terminal emulator:
Code:
a. Failed to connect to the session manager: None of the authentication
protocols specified are supported. GLib-GIO:ERROR:gdbusconnection.c:2270:
initable_init: assertion failed: (connection->initialization_error == NULL)

b. cannot connect to the session bus: org.freedesktop.DBus.Error.NoReply:
Did not receive a reply. Possible causes include: the remote application
did not send a reply, the message bus security policy blocked the reply, [color="Purple"]etc.[/color]
c. GDM pitches in with its 2 (or 50) cents:
Code:
Window manager warning: meta_window_activate called by a pager with a 0 timestamp; 
the pager needs to be fixed.
CurrentTime used to choose focus window; focus window may not be correct.
Got a request to focus the no_focus_window with a timestamp of 0. 
This shouldn't happen!

Unfortunately, my google search did not turn up with much relevant answers on the topic. Thanks in advance.
 
yes, both are running, in rc.conf these (hald, dbus, gdm, gnome) are enable="YES".
Relevant output from # ps -ax
Code:
Is     0:00.16 /usr/local/bin/dbus-daemon --system
Is     0:00.92 /usr/local/sbin/hald
I      0:00.10 /usr/local/sbin/console-kit-daemon --no-daemon
I      0:00.15 /usr/local/libexec/polkitd
S      0:00.38 /usr/local/libexec/gam_server
I      0:00.03 hald-runner
I      0:00.01 hald-addon-mouse-sysmouse: /dev/psm0 (hald-addon-mouse-sy)
I      0:00.06 /usr/local/libexec/gdm-simple-slave --display-id /org/gnome/Disp
S      1:57.23 /usr/local/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-
I      0:00.00 /usr/local/bin/dbus-launch --exit-with-session
I      0:00.10 /usr/local/libexec/polkit-gnome-authentication-agent-1
I      0:00.02 /usr/local/libexec/gdm-session-worker
I      0:00.04 /usr/local/libexec/upowerd
I      0:00.04 /usr/local/bin/gnome-keyring-daemon --daemonize --login
Is     0:00.27 gnome-session
I      0:00.00 dbus-launch --exit-with-session /usr/local/bin/seahorse-agent --
Is     0:00.37 /usr/local/bin/dbus-daemon --fork --print-pid 5 --print-address 
Is     0:00.05 /usr/local/bin/seahorse-agent --execute gnome-session
S      0:00.21 /usr/local/libexec/gvfs-hal-volume-monitor
I      0:00.06 /usr/local/libexec/polkit-gnome-authentication-agent-1
 
The same thing on 8.2-release i386. 8.1-stable amd64 looks like works fine. Ports are up to date and upgraded on both systems.
 
I can confirm similar.

When gnome-session is started the old way with dbus-launch, all works well. With ck-launch, it does not. ck-list-sessions shows two sessions, first one has a value of TRUE, second one has a value of FALSE for "active" ...

My guess is that ck-launch is not enabling DBUS properly.

Have overload of work tonight and tomorrow on my end - if this doesn't help trigger some thoughts on the matter, will offer more assistance on Friday night or Saturday but thought my information here might help to properly point the finger.
 
Here's the relevant output from ck-list-sessions

Code:
[user@64bit ~]$ ck-list-sessions
Session1:
	unix-user = '1001'
	realname = 'user'
	seat = 'Seat1'
	session-type = ''
	active = TRUE
	x11-display = ':0'
	x11-display-device = '/dev/ttyv8'
	display-device = '   ?   '
	remote-host-name = ''
	is-local = TRUE
	on-since = '2011-03-19T00:55:50.778200Z'
	login-session-id = ''
Session2:
	unix-user = '1001'
	realname = 'user'
	seat = 'Seat2'
	session-type = ''
	active = FALSE
	x11-display = ':0'
	x11-display-device = '/dev/ttyv8'
	display-device = '   ?   '
	remote-host-name = ''
	is-local = FALSE
	on-since = '2011-03-19T00:55:51.274081Z'
	login-session-id = ''
[user@64bit ~]$

since "active" and "is-local" on the second session are FALSE, I would assume that this is likely to be the reason why gvfs is not automounting to the desktop nor is the shutdown option appearing under "Log out user" on the System dropdown at the top of the menu.
 
Just wanted to also confirm that I have verified and REverified that everything is in compliance with both the latest 2.32 FAQ and the HAL FAQ as far as to configuration.
 
My ck-list-sessions gives only 1 user:
Code:
unix-user = '1001'
	realname = 'some guy'
	seat = 'Seat1'
	session-type = ''
	active = TRUE
	x11-display = ':0'
	x11-display-device = '/dev/ttyv8'
	display-device = '   ?   '
	remote-host-name = ''
	is-local = TRUE
	on-since = 'the middle ages'
	login-session-id = ''
I suspect that the real problem here is that login-session-id is blank as this is what the error log is telling us. AFAIK this is how gnome security (like seahorse) keeps track of authorisations, somewhat independently from the unix-user id number (??).

There seems to be a partial answer here, but I don't quite get it:
http://lists.freedesktop.org/archives/polkit-devel/2009-December/000285.html
 
Not sure if this is going to help you, but it did solve my own problem.

First off, I pulled the plug on ck-launch and reverted back to dbus-launch and therefore something definitely is amiss with ck-launch. While this might not be of any help to you, possibly the following WILL be.

I added the following line to the /etc/pam.d/gdm-autologin file:

Code:
session	   optional	/usr/local/lib/pam_gnome_keyring.so	auto_start

The reason why I looked at replacing dbus-launch with ck-launch in the first place was because startup time for gnome was unacceptably long. However, adding the above now makes the speed of dbus-launch comparable to using ck-launch and so I consider my problem solved, though not the way I would have preferred. And yes, when using dbus-launch, only one seat is listed in ck-list-sessions and it's active as expected.
 
@KNOStic: Thanks for the input, but as you expected, your mods did not fix the problem on my system.

A large number of gui apps misbehave in the x11/gnome environment and I suspect it is due to this error. Any way I can diagnose the problem? Log files have limited info.

UPDATE: This looks like a bug (?) found on the PC-BSD 9.0 Testing issues page, dated Jan 27 2011: http://lists.PC-BSD.org/pipermail/testing/2011-January/004923.html
gnome-keyring-daemon[2521]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk.

Not sure if this a FreeBSD bug with gnome-keyring-daemon, its just the standard port build, and can't find any additional information on why this warning is thrown.
 
Last edited by a moderator:
this seems to be mlock issue

Some more goooogleing regarding this issue and I have come accross several reported cases that this is an mlock problem; does not play nice with gnome-keyring-daemon. Various quotes:
gnome-keyring-daemon calls mlock to make the memory not swapped out of memory, but by default, Solaris users don't have this priviledge. You can add the following line into /etc/security/exec_attr: Basic Solaris
User:solaris:cmd:::/usr/bin/gnome-keyring-daemon:privs=proc_lock_memory
This error will always be seen since FreeBSD's mlock() requires setuid privileges, and g-k-d cannot run as setuid
Thoughts anyone?
 
Same problem here http://www.daemonforums.org/showthread.php?p=4395

its not running as root. you could make the program suid but IMO making a program suid thats not been carefully written and audited is a greater risk than someone reading sensitive info paged out to disk.
i would suggest that you ignore the error messages and if it bugs you too much you could disable it via syslog.conf. if you still have any doubts then write to the port maintainer.

You can disable console notification. Remove the line:

Code:
#*.err;kern.debug;auth.notice;mail.crit         /dev/console
from /etc/syslog.conf

OR redirect it to a file:

Code:
*.err;kern.debug;auth.notice;mail.crit          /var/log/console.log
 
I see the same error messages as Beeblebrox. I'm not sure whether this is related, but in my case I can't use sftp with nautilus. (thread "nautilus and ssh problem").

Is there any ideas how to debug this or solution yet, since in my eyes this looks more like a general problem?
 
I just had a short look at it and I did not find any differences between my pam.d/gdm file (default after gdm install) and the one described in the gnome tutorial. However error messages are still present.
 
I just had a short look at it and I did not find any differences between my pam.d/gdm file (default after gdm install) and the one described in the gnome tutorial. However error messages are still present.

Post files you edited
 
I tried the solution in the link but it did not work for me either; so no change.

1. The pam tests work if you run them in their relevant folders:
$ cd /usr/local/lib && grep -rq pam_gnome_keyring.so
$ cd ~ && test -f ~/.gnome2/keyrings/login.keyring

2. FreeBSD does not have the file /etc/pam.d/gdm. If you try to create one, pam re-names it to gdm_disabled. But there is a file xdm. so I placed these in /etc/pam.d/xdm:
Code:
auth    optional        pam_gnome_keyring.so
session optional        pam_gnome_keyring.so  auto_start
@ mzettler: For ssh look at the end of the page http://live.gnome.org/GnomeKeyring/Pam/Manual. The page also has a link to gnome-keyring ssh.
Gnome Keyring implements its own SSH agent, therefore you should not stack it with pam_ssh for session management
 
You can "setuid root" with these two commands:

Code:
# chown root /usr/local/bin/gnome-keyring-daemon
# chmod u+s /usr/local/bin/gnome-keyring-daemon

The first command makes root the "owner" of the gnome-keyring-daemon binary (in case root didn’t already have ownership of the file). The second makes the program run with the privileges of its "owner" no matter who started it up.

Remember that "setuid root" is bad for security purposes.
 
Back
Top