On 03/29/2013 12:16 PM, m.roth@xxxxxxxxx wrote:
> I've finally got it working. First, I create that file
> /etc/X11/xinit/Xclients.d/Xclients.gnome-session.sh, whose contents are
> #!/bin/sh
> exec -l $SHELL -c "$SSH_AGENT gnome-session"
I just realized that Xclients.gnome-session.sh is called as:
exec -l $SHELL -c "$CK_XINIT_SESSION $SSH_AGENT
$XCLIENTS_D/Xclients.$1.sh"
... which means that Xclients.gnome-session.sh is executed in an empty
environment, which is why you're not getting two ssh-agents. It also
means that it'll execute the same commands as:
#!/bin/sh
exec gnome-session
> Now, I do *not* have a clue of the impact of not letting
> gnome-keyring-agent run. If someone here does, feel free to discuss it,
> and let me know if I *can* just chmod -x.
You *can*, but the users will lose GPG, PKCS11, and "secrets" support.
IIRC, that means they can't do any local admin stuff, because GNOME
can't prompt them for passwords any longer.
It'll also be reset whenever you update GNOME packages.
You're better off removing read access to
/etc/xdg/autostart/gnome-keyring-ssh.desktop, but that will also be
reset whenever you update. (I've tested this)
If the user turns off SSH support in gnome-session-properties, the
change will not be impacted by upgrades, so that's the most reliable
thing. (I've tested this, too)
> Anyway, my hack which works neatly is to create a three line shell script
> that goes into the users .<shellrc> file, whose contents are:
Normally you'd want to put environment variables like that into
.bash_profile instead, so that it's not called by non-login shells.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
