start gpg-agent with systemd

[Łukasz Stelmach]

It was <2012-10-18 czw 21:00>, when Werner Koch wrote:
> On Thu, 18 Oct 2012 17:52, l.stelmach at samsung.com said:

Thank you for your reply. Let me ask, however, few more questions and
describe my idea in greater details.

>> I work on systemd integration both as a replacement for init as well as
>> user session manager. I've tried to start gpg-agent as a part of user
>> serssion and found it does not fit well there. Agent's default behavior
>> (socket in a randomly named directory) and the information printed on
>> stdout or saved in a file is hard to handle.
>
> For quite some time now this default may be changed with a configure
> option.  2.1 will make this the new default.  The rationale for this
> change is that the majority of systems do not use remote mounted home
> directories which won't work with local sockets.  Those installations
> with these problems will anyway be controlled by sysadmins who can
> change the default (with a gpg-agent.conf option).

Yes I've seen it I and wanted use this code path and check if
XDG_RUNTIME_DIR is set and prefer it over opt.homedir.

I was wondering why the option named --use-standard-socket is an option
:)

>> 1. Do you, Gnupg developers, want such a feature and will you accept
>> such a patch (of course only if it meets your quality standards).
>
> No.  If systemd does not adhere to Unix standards, it is the problem of
> systemd.  GnuPG is a portable application and in no way limited to
> Linux.

In what parts (that would affect gpg-agent) in your opinion systemd does
not adhere to Unix standards? (I am simply curious.)

>> 2. Other systemd syservices use $XDG_RUNTIME_DIR[fn:1] to put their
>> runtime stuff (sockets, flags). I'd like gpg-agent to use it too.
>
> If that becomes part of POSIX, we can talk about it.

Could there be an option to place the socket(s) in an arbitrary
directory and not necessarily choose between /tmp/gnupg-XXXX/ and ~/.gnupg?
Of course systemd can create a socket in ~/.gnupg/ too.

>> 3. GPG_AGENT_INFO variable holds agent's PID. It is passed to assuan
>> library function that connects to a socket but isn't used there. Is it
>> going to be required in the future? Passing this information during
>> parlell startup "sequence" without locking and waiting for the agent to
>> start is impossible as well as during socket-activated start.
>
> It is not used.  But, as mentioned above: The new default will be an on
> demand started gpg-agent and that should solve all your problems.  In
> fact we use that on Windows for many years now.

I see. With the socket in a standard place this is feasible. However, it
is only systemd's socket activation that could start gpg-agent on reqest
from ssh client.

The change required to use the socket activation isn't IMHO big. Systemd
binds a Unix socket and starts listening. When a new conection comes
then, depending on the value of Accept[1] option:

true - it accepts the connection and spawns a server process to handle
       it and passes a *connected* socket as stdin/stdout, and keeps
       listening.

false - it spawns the server and passes the *listening* socket as
        stdin/stdout and it is servers responsibility to accept(2) the
        connection. systemd starts listening again only when the server
        exits.

My idea was to use Accept=false (think inted's wait) and change the code path
for the --server option to check if the stdin is a socket and wait for
another connection rather than exit upon BYE.

On the other hand some changes to systemd might be required to to handle
two sockets with one server.

Best regards.

Footnotes:

[1] http://www.freedesktop.org/software/systemd/man/systemd.socket.html
-- 
Łukasz Stelmach
Software wizzard
Samsung Poland R&D Center

Al. Armii Ludowej 26, 00-609 Warszawa
http://www.rd.samsung.pl