Wishlist: $SSH_AUTH_SOCK in $XDG_RUNTIME_DIR

[Daniel Richard G.]

This is a wishlist item for openssh-client 6.0p1-3ubuntu1 in Ubuntu Quantal.

Now that XDG_RUNTIME_DIR support is available, it would be nice if the /etc/X11/Xsession.d/90x11-common_ssh-agent X session startup script would check to see if the variable is set, and if so, pass an argument to ssh-agent(1) so that the Unix-domain socket is created in /run/user/$USER/* rather than /tmp/ssh-*/.

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

/etc/X11/Xsession.d/90x11-common_ssh-agent is actually provided by x11-common (source package xorg), and it makes sense to me for XDG related code to stay in there anyway.

[penalvch (penalvch)]

Daniel Richard G., as Ubuntu syncs with upstream, any WISHLIST would want to be implemented upstream first, and then it would be pulled downstream in Ubuntu, not vice versa. If reproducible in xorg trunk, please feel free to report this to them via https://bugs.freedesktop.org/ .

[Daniel Richard G. (skunk)]

Christopher,

This wishlist item is properly implemented in a system script (/etc/X11/Xsession.d/90x11-common_ssh-agent) authored and provided by Debian/Ubuntu, not by Xorg upstream. The file path in the source tree is

    xorg-7.6+12ubuntu2/debian/local/Xsession.d/90x11-common_ssh-agent
    (as of Ubuntu Precise)

Please revert the status to New. This item has been filed correctly.

[penalvch (penalvch)]

Daniel Richard G., thank you for your comments. The earliest discussion found supporting this so far would https://mail.gnome.org/archives/desktop-devel-list/2008-January/msg00006.html . Given as you noted in https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1131383/comments/3 this is properly implemented, would this accomplish your objective as outlined in the Bug Description, or would there be anything further to consider?

[Daniel Richard G. (skunk)]

Christopher,

Let me rephrase what I said: This wishlist item properly belongs in 90x11-common_ssh-agent; it has yet to be implemented.

That GNOME discussion from six years ago is not relevant here. Fedora may be doing something like what is described in that thread, but Debian/Ubuntu are not.

If Debian/Ubuntu are proposing to change the way that the agent is handled that would obviate the need for this wishlist item, then feel free to mention it. If you are a maintainer of Ubuntu's OpenSSH packages and would like to discuss the merits of this approach, then by all means do so. It is inappropriate, however, for you as a Bug Control member to change the status of a wishlist item to WONTFIX unless you are also an Ubuntu developer and you have a reason not to implement the item. (You may want to review https://wiki.ubuntu.com/Bugs/Status)

Please revert the status of this bug to NEW.

[penalvch (penalvch)]

Daniel Richard G., thank you for your comment. At this point, given the request has a clear scope, although limited discussion on PROS/CONS, no demo code, or whether this should be done upstream in a vendor neutral way versus downstream vendor patching, New would not be appropriate here. I'll mark this Triaged so that the discussion may continue.

Thank you for your understanding.

[Daniel Richard G. (skunk)]

Christopher: thanks.

Upstream patching isn't really applicable here, because the script in question is distribution-specific session-setup code.

As for demo code, here's a tidbit to get the ball rolling:

    if [ -n "$XDG_RUNTIME_DIR" -a -d "$XDG_RUNTIME_DIR" ]; then
      SSHAGENTARGS+="-a $XDG_RUNTIME_DIR/ssh-agent.$$"
    fi

(added right after the "SSHAGENTARGS=-1" conditional)

A couple advantages of this are

1. Old agent sockets are less likely to stick around, because /run/ is a tmpfs;

2. Searching for my own ssh-agent socket(s) is easier/safer, because I don't have to worry about /tmp/ssh-*/ directories that belong to someone else, or (worse) a hostile attacker.

[penalvch (penalvch)]

Daniel Richard G., given the upstream for 90x11-common_ssh-agent in this case would be debian, specifically, Debian X Strike Force, I would shoot them a mail via <email address hidden> as it would provide a wider audience for this request.