[PATCH] dirmngr: implement --supervised command (for systemd, etc)

[Daniel Kahn Gillmor]

Hi Justus--

Thanks for the additional thoughts!

On Thu 2016-08-11 09:21:44 -0400, Justus Winter wrote:
> Having said that, there are concerns with this kind of feature.  First
> of all, this must not change where the log messages go.  What good is it
> if they are collected by systemd but are missing in the gnupg log?

Well, there is no general "gnupg log" that i'm aware of -- but i'm fine
with re-enabling the log-file directive in --supervised mode if you
prefer it that way.

> Then, how are we going to tell from bug reports that a user is using
> some service manager, as opposed to letting gnupg handle its background
> servers by itself?

i don't think gpg itself can tell the difference one way or another --
if the service is listening on the expected port, gpg will use it.  We
had this issue already in some sense with gnome-keyring "hijacking"
gpg-agent (and, arguably, ssh has this issue with gpg-agent "hijacking"
ssh-agent).  But in the system supervision case it's actually still the
same gpg-agent that's running, not an imposter.  it's just be started up
automatically without exercising any of the auto-spawning code.

> Worse, if users are having trouble with this, how are we going to debug
> it, given that we do not use e.g. systemd ourself?

i don't know which "we" you mean, but as a community, we support GnuPG
users on GNU/Linux, Windows, Mac OS, AIX, FreeBSD, VMS, Solaris, etc.
Surely we don't all run all of those.  I understand the wariness of
adding a new mode to support, but systemd is hardly a niche system
management suite, and the changes here are not particularly large.
There is considerably more code in dirmngr that is only for the purposes
of supporting one specific OS (Windows) than there is in the patchset
i've proposed.

> Furthermore, it is not clear what benefits users will have if systemd
> manages our services.

Hm, I thought i'd made this clear, but i'll try to set it out more
formally.

The goal here is to have a single daemon that runs for a given user for
the duration of the time they're logged into a computer.  It's possible
that there are multiple concurrent logins for a given user -- for
example, two different ssh sessions, or a graphical login and a
text-mode login concurrently on the same machine.

There are a few desiderata for any daemon that we're trying to handle in
this way:

 0) do not start the daemon unless something the user does actively
    needs it.

 1) do not run multiple instances of the daemon for any given user.

 2) cleanly and promptly terminate the daemon when the user has
    no more running sessions on the machine.

Recent versions of gnupg support desiderata 0 and 1 fairly well out of
the box, but i've seen no concrete proposals for how to deal with 2, and
some legitimate complaints about it (see an earlier Subject: in this
thread, which came from debian developer Ian Jackson: "Beware of
leftover gpg-agent processes").

Even without --supervised mode, we can solve 1 and 2 on systemd and
other session-tracking system service managers by manually starting a
service for each daemon; this lets us safely clean up the daemon at
session termination (because we started it, and we can track and safely
tear down itself and any children it might spawn).  But we don't solve
desideratum 0 in this case, because the daemons are running even when
you don't want them.

We can solve 0, 1, and 2 together on systems that use systemd by using
socket activation, as proposed here.

An additional gain (which you may not care about as a non-user of
systemd) is that there are other per-user or per-session daemons that
are managed in the same way; being able to address each of the daemons
in the same way, to inspect their status, to restart them, etc, is a
feature for people who don't necessarily have the time to learn
idiosyncrasies of each of the daemons that support their computing
environment.  This kind of system integration allows for the creation of
simple quick overview tools of machine state (e.g. "systemctl --user
status"), standardized logging (e.g. "journalctl --user -u gpg-agent"),
and for standardized ways of constraining or controlling these daemons
(e.g. Limit*=, AppArmorProfile=, and other directives in
systemd.exec(5)).  By integrating with a common management model in a
specific operating environment, there's a lot that a program can get
"for free" as it piggybacks on other infrastructure.

> And please don't say that the benefit is that things are continue to
> work despite the fact that systemd starts to randomly kill services
> that are neither managed by it nor are communicating their with to
> live via some dbus interface.

eh?  It sounds to me like you're aware of some complaint or bug report
i'm unware of.  Could you explain more, or point me to a specific
example, please?  I've been running systemd for quite some time and i've
never seen any random killing or any requirements of reporting to a dbus
interface.

Certainly, you can configure systemd to act as a "watchdog" and have it
kill processes that don't report regularly to a dbus interface,
(i.e. WatchdogSec= in systemd.service(5)), but i don't see why anyone
would ever configure that option for daemons like dirmngr or gpg-agent
that don't talk to dbus.  I certainly didn't in my example .service file
:)

Regards,

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: </pipermail/attachments/20160811/cd7c880a/attachment.sig>