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

[Daniel Kahn Gillmor]

Hi Werner--

Thanks for the feedback, and for merging those logging patches!

On Fri 2016-08-12 06:12:57 -0400, Werner Koch wrote:
> My advise has always been to put 
>
>   log-file socket:///home/user/.gnupg/S.log
>
> into the conf files and use watchgnupg to read or log them.  In fact
> that is what kmail does with its kwatchgnupg.

I see this advice is in doc/tools.texi, but i don't see it used often.
'S.log' for GnuPG doesn't show up anywhere else in debian, for example:

 https://codesearch.debian.net/search?q=%5CWS%5C.log%5CW&perpkg=1

Anyway, i'm happy to support this case, and have made sure in this
latest series that log-file is still supported in the --supervised mode.

>> 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.
>
> How do you convey the envvars to gpg-agent?  What systemd does is
> different from what gpg will do; for example the default tty, DISPLAY,
> and locale may be different.  gpg will also pass --homedir to the
> invocation of gpg-agent if gpg has been started this way.

gpg conveys envvars to gpg-agent during its use.  This is what allows us
to run a single daemon that responds to requests from multiple
concurrent sessions, right?

>> 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.
>
> Actually we are not using dirmngr as a system service on Windows for
> some years.  Thus most of this code is subject to removal.

Great!  i'm always happy to hear about code removal in complex
projects. :) Even aside from the system service, there's still a lot of
Win32-specific code, though.  This is not meant as a critique -- i think
it's a good thing that GnuPG is capable of supporting people on Windows,
even though it's not a platform i'd ever recommend or use myself.  I
recognize that some people are stuck there and we should be supporting
them.

>>  2) cleanly and promptly terminate the daemon when the user has
>>     no more running sessions on the machine.
>
> For dirmngr this is not a good idea because we plan to add background
> tasks (parcimonie).

I'd be a little surprised if most people expected a parcimonie-style
updater to run (and update their keyring, etc) when they weren't
actually logged into the computer.  parcimonie itself certainly doesn't
do that.

But for someone who does want to do that, these changes don't prevent
them from launching dirmngr explicitly in a non-supervised scope.

> For gpg-agent there valid use cases to keep on running gpg-agent even
> after all user sessions are closed.  For example a server is using a
> smartcard to autheniticate connections done via cron.  Terminating the
> gpg-agent and thus gpg-agent would reset the smartcard and require the
> operator to open a session to enter the PIN again.

Those use cases are definitely valid, and they're still supported: the
user just doesn't use --supervised.

however, the common use case, where users want daemons running alongside
their session, and *don't* want gpg-agent still running and using the
smartcard after they log out will be better handled with some sort of
system integration.

> A simple solution would be to "gpgconf --reload gpg-agent" after logout
> of any session.  This will flush the caches and thus no sensitive
> information is held by the agent.  This might be a bit annoying for
> other sessions using gpg-agent becuase they need to re-enter their
> passphrase, but I guess people can live with that.  Or just kill the
> gpg-agent at session end, it will be restarted anyway as needed.

I agree that killing the agent at any logout is better than the current
non-integration with any sort of session management (though i agree that
it might be a little frustrating for one ephemeral login to drop a hot
cache for a long-running login).

This sounds like a reasonable proposal for systems that don't have
structured session management.  Any suggestions for where to encourage
this setup on such a system?

> For killing I added a feature to tell the number of active connections
> to gpg-agent, so that a logout script can gracefully kill gpg-agent.
> But even that is not required because a single SIGTERM will delay
> termination until all connections are close.

right, this bit is fine no matter how we resolve it.  Thanks for making
sure this engineering is solid.

> Another option is that gpg-agent can be changed to terminate itself some
> time after all cache entries are expired.

Yes, this would be really useful approach, and seems like it'd be a good
thing to do regardless of how this patch series works out.  The only
concern i'd have would be about how to get the agent to respawn for use
by ssh (though the socket-activation i'm proposing does solve that
problem).  It would still leave sessions open in the background for
several minutes after logout in some common use cases, but it would be
far better than having live code running indefinitely.

I'm assuming this would be a new configuration option for gpg-agent.
Maybe --terminate-after-idle ?  What should it default to?  I can send
patches for this feature if you want it.  the other question is what
counts as "idle" -- it's not just that nothing is in the cache, right?
might also want to count commands like PUTVAL as a timer reset...

>> 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").
>
> One gpg-agent process per user, unless several have been started from
> different home directories.  In fact gpg-agent has a self-check to make
> sure that only one instance is running for a given homedir (technically
> for a given socket).
>
> BTW, I wish Ian would finally apply the Tor patches to adns after more
> than one year of asking him.  It is annoying that we have full Tor
> support only on Windows.

Totally agreed.  Is there a canonical place where this is discussed, or
where the patches live?  I've seen discussions on it here on
gnupg-devel, but there wasn't anything in the debian or GNU bts until i
filed this earlier today:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24212

>> 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"),
>
> <scnr>Sounds like Windows and not like Unix</>

System-wide overviews and standardized tooling ("do one thing and do it
well") aren't unix-like‽ We should probably change that ;) But
seriously, i'm not interested in this as a religious conflict; i'm
interested in good system integration on platforms that i care about and
can do something about.  GNU/Linux with systemd as pid 1 is one such
platform today.  I'm pretty sure we can both acknowledge that good
defaults that don't require research or special knowledge are important
for making tools that normal users can actually use.  And I'm also
pretty sure we both want GnuPG and its related tools to be usable by
normal people.  right?

>> 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
>
> See the recent LWN article about systemd terminating all processes  at
> session close including nohup'ed processes.

This is hardly "randomly killing" -- it's attempting to fix the problem
that (for example) some daemon might remain active and doing things "on
your behalf" after you thought you'd terminated your session.  I agree
that terminating the nohup'ed processes was overreach, but the problem
they're attempting to solve is a real one.

>> Certainly, you can configure systemd to act as a "watchdog" and have it
>> kill processes that don't report regularly to a dbus interface,
>
> GnuPG does not use dbus.  Long ago I considered to add support for this
> but after checking all the dependencies and code required for dbus I
> figured that this is not a good idea and could only be added using an
> external helper.

Sure -- i was not proposing that we'd do this for gpg-agent or for
dirmngr.

> What your proposed change won't solve is the ssh-agent support.  Well
> gpg-agent would be started by ssh as needed - cool.

right, it solves this part of the problem, but...

> But the also important point on how to convey the envvars to gpg-agent
> is not solved

... it doesn't solve https://bugs.debian.org/830658

> this requires changes to the ssh-agent protocol and code changes to
> ssh, proper.  Now if those changes are anyway required, the
> autostarting can be added as well.

I'm not sure this is the only way to solve the problem, and i have
pretty serious doubts about getting autostarting of gpg-agent into ssh.

The problem isn't transmitting envvars in itself, it's figuring out how
the agent should get a prompt back to the user.

Historically, we've done that in GnuPG by passing env vars over the
assuan socket.  As long as you're OK with this kind of opportunity for
leakage (processes in session B can take control of the agent without
session A knowing about it), and your clients know what needs to be to
sent, this is fine.

And ssh has historically done that by having the agent just know the
correct env vars in the first place, and never deviating.  As long as
you're OK with no leakage (session B can't use the agent without session
A knowing about it), this also works fine.

But they're not the same tradeoffs :/

In particular, the ssh-agent model assumes one agent *per X11 session*,
and gpg-agent assumes one agent *per user*.  If the agent's
notifications were done per-user instead of per-X11 session, then the
environment variables wouldn't necessarily be relevant, right?

I need to think more about how we might approach this sanely, but it
seems like you could potentially address it with a pinentry/ssh-askpass
that is aware of how the parent daemon's lifespan is scoped.

However we solve those problems, having process supervision and socket
activation still seem like good things, so i'd still like these patches
to be considered by upstream GnuPG.  I don't think they break any
existing non-systemd workflow, and they provide concrete benefits to
people using machines configured with systemd.

I welcome feedback on the proposed implementation and interfaces.

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/20160812/5d42f6e5/attachment.sig>