Comment 4 for bug 377467

Revision history for this message
Mikel Ward (mikelward) wrote :

Lots of weirdness.

$ cat ~/.xsession-errors
/etc/gdm/Xsession: Beginning session setup...
Agent pid 12447
Identity added: /home/mward/.ssh/id_rsa (/home/mward/.ssh/id_rsa)
Warning: Only changing the first 3 of 32 buttons.
Setting IM through im-switch for locale=en_AU.
Start IM through /etc/X11/xinit/xinput.d/all_ALL linked to /etc/X11/xinit/xinput.d/default.
I: caps.c: Limited capabilities successfully to CAP_SYS_NICE.
I: caps.c: Dropping root privileges.
I: caps.c: Limited capabilities successfully to CAP_SYS_NICE.
N: main.c: Called SUID root and real-time and/or high-priority scheduling was requested in the configuration. However, we lack the necessary privileges:
N: main.c: We are not in group 'pulse-rt', PolicyKit refuse to grant us the requested privileges and we have no increase RLIMIT_NICE/RLIMIT_RTPRIO resource limits.
N: main.c: For enabling real-time/high-priority scheduling please acquire the appropriate PolicyKit privileges, or become a member of 'pulse-rt', or increase the RLIMIT_NICE/RLIMIT_RTPRIO resource limits for this user.

(gnome-settings-daemon:12699): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed

(gnome-settings-daemon:12699): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
GNOME_KEYRING_SOCKET=/tmp/keyring-ZC3meK/socket
SSH_AUTH_SOCK=/tmp/keyring-ZC3meK/socket.ssh
...

And then looking in /etc/gdm/Xsession...

# good for debugging where things went wrong
echo "$0: Beginning session setup..."

# First read /etc/profile and .profile
test -f /etc/profile && . /etc/profile
test -f "$HOME/.profile" && . "$HOME/.profile"
# Second read /etc/xprofile and .xprofile for X specific setup
test -f /etc/xprofile && . /etc/xprofile
test -f "$HOME/.xprofile" && . "$HOME/.xprofile"

Why is it sourcing my ~/.profile? That's wrong!

$ head ~/.profile | grep echo
echo "$(date) profile SSH_AGENT_PID=$SSH_AGENT_PID SSH_AUTH_SOCK=$SSH_AUTH_SOCK gnome-keyring=$(pgrep -d , -f gnome-keyring) ssh-agent=$(pgrep -d , -f ssh-agent)" >> $HOME/.sh.log
$ head ~/.shrc | grep echo
echo "$(date) shrc SSH_AGENT_PID=$SSH_AGENT_PID SSH_AUTH_SOCK=$SSH_AUTH_SOCK gnome-keyring=$(pgrep -d , -f gnome-keyring) ssh-agent=$(pgrep -d , -f ssh-agent)" >> $HOME/.sh.log
$ cat ~/.sh.log
Mon May 18 09:39:45 EST 2009 profile SSH_AGENT_PID= SSH_AUTH_SOCK= gnome-keyring=12408 ssh-agent=4198
Mon May 18 09:40:31 EST 2009 shrc SSH_AGENT_PID=12447 SSH_AUTH_SOCK=/tmp/keyring-ZC3meK/socket.ssh gnome-keyring=12408 ssh-agent=4198,12447
$ ps -fp 4198
UID PID PPID C STIME TTY TIME CMD
mward 4198 1 0 09:05 ? 00:00:00 ssh-agent
$ ps -fp 12408
UID PID PPID C STIME TTY TIME CMD
mward 12408 1 0 09:39 ? 00:00:00 /usr/bin/gnome-keyring-daemon --daemonize --login

I logged in at 9:39, so the ssh-agent is from my previous log in.

It also shows that GNOME Keyring Daemon is already started before my ~/.profile is sourced, but that SSH_AUTH_SOCK is unset.

So the /etc/gdm/Xsession stuff is arguably a bug, and GNOME Keyring Daemon should probably be setting SSH_AUTH_SOCK as soon as it's started via PAM, but it doesn't look like it is (or something is nuking the environment).