Mailing List Archive

Management of background services with systemd
I am researching GnuPG for my employer. We will stick with the old release series 2.2 at first, because few Linux distributions package 2.3 or 2.4 yet. However, I'm studying newer versions and recent developments to ease our future upgrades. In doing so, a question has arisen: should background services like the agent not be managed with systemd?

Daniel Kahn Gillmor [introduced][1] and maintained systemd unit files and also implemented `--supervised` for the [agent][2] and [dirmngr][3] as part of version 2.1.16. However, `--supervised` has been [deprecated][4] since version 2.3.6 and Werner recently [removed the systemd unit files][5] altogether. In fact, he commented the following on [task T6336][6] about two months ago:

> Actually, the entire systemd based launching is deprecated and thus the logged warning [about `--supervised`] is on purpose.
>
> The problem with the systemd launched gpg-agent is that it creates a race: gpg launches gpg-agent as needed and to avoid concurrent launching by other gpg or gpgsm processes, it takes a file system lock during the launch process. systemd does not know about this and we end up with sometimes end up with two gpg-agent processes. Eventually one of those processes detects that it does not own the socket and terminates itself. No real harm here but you may see smart card lockups or a flushed password cache.

For what it's worth, the systemd setup (as packaged with series 2.2) works very well for me. In particular:

- background services are managed through a common interface (that of systemd);
- logs are centralized; and
- the agent starts whenever OpenSSH needs it, thanks to socket activation.

I have experienced only one limitation: there is no convenient way for systemd to manage background processes for [ephemeral home directories][7], which I have been using extensively for my research & testing.


[1]: https://dev.gnupg.org/rG57e95f5413e21cfcb957af2346b292686a5647b7
[2]: https://dev.gnupg.org/rG9f92b62a51d2d60f038fdbe01602865c5933fa95
[3]: https://dev.gnupg.org/rG75f8aaf5bc2dc7fcffe2987a572d489155c91eb9
[4]: https://dev.gnupg.org/rGca5d5142c6d6eaba4572a086f8473e4aebdd3f9e
[5]: https://dev.gnupg.org/rGeae28f1bd4a5632e8f8e85b7248d1c4d4a10a5ed
[6]: https://dev.gnupg.org/T6336
[7]: https://www.gnupg.org/documentation/manuals/gnupg/Ephemeral-home-directories.html

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Management of background services with systemd [ In reply to ]
On Thu, Mar 2, 2023 at 5:31?AM David Joaquín Shourabi Porcel
<david@djsp.eu> wrote:
>
> //snip
>
> I have experienced only one limitation: there is no convenient way for systemd to manage background processes for [ephemeral home directories][7], which I have been using extensively for my research & testing.
>

So it would be helpful if someone steps up to add systemd interface,
as long as it's cleanly decoupled from other parts of gnupg,
so that no extra effort is necessary from other developers,
and nothing is lost when gnupg is used on systems with service and log
management interfaces other than systemd.

>
> [1]: https://dev.gnupg.org/rG57e95f5413e21cfcb957af2346b292686a5647b7
> [2]: https://dev.gnupg.org/rG9f92b62a51d2d60f038fdbe01602865c5933fa95
> [3]: https://dev.gnupg.org/rG75f8aaf5bc2dc7fcffe2987a572d489155c91eb9
> [4]: https://dev.gnupg.org/rGca5d5142c6d6eaba4572a086f8473e4aebdd3f9e
> [5]: https://dev.gnupg.org/rGeae28f1bd4a5632e8f8e85b7248d1c4d4a10a5ed
> [6]: https://dev.gnupg.org/T6336
> [7]: https://www.gnupg.org/documentation/manuals/gnupg/Ephemeral-home-directories.html
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users

Guan

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Management of background services with systemd [ In reply to ]
David Joaquín Shourabi Porcel <david@djsp.eu> wrote:
> I am researching GnuPG for my employer. We will stick with the old
> release series 2.2 at first, because few Linux distributions package
> 2.3 or 2.4 yet. However, I'm studying newer versions and recent
> developments to ease our future upgrades. In doing so, a question has
> arisen: should background services like the agent not be managed with
> systemd?

Please no.

It's bad enough as it is when you have multiple personalities you are trying
to support (signing as me, vs signing code with an offline key)... having
systemd (the userland one) popping off new copies would be horrible.

Combined with SSH access to the machine, and the passphrase/pin popup shows
up in the wrong place.

(And many of us do not trust systemd and do not run it on important machines)
Re: Management of background services with systemd [ In reply to ]
On Wed, Mar 01, 2023 at 09:24:35PM -0500, Michael Richardson <mcr@sandelman.ca> wrote:

>
> David Joaqu?n Shourabi Porcel <david@djsp.eu> wrote:
> > I am researching GnuPG for my employer. We will stick with the old
> > release series 2.2 at first, because few Linux distributions package
> > 2.3 or 2.4 yet. However, I'm studying newer versions and recent
> > developments to ease our future upgrades. In doing so, a question has
> > arisen: should background services like the agent not be managed with
> > systemd?
>
> Please no.
>
> It's bad enough as it is when you have multiple personalities you are trying
> to support (signing as me, vs signing code with an offline key)... having
> systemd (the userland one) popping off new copies would be horrible.
>
> Combined with SSH access to the machine, and the passphrase/pin popup shows
> up in the wrong place.
>
> (And many of us do not trust systemd and do not run it on important machines)

Having systemd control gpg-agent can be a huge problem
even with a single personality. If you want a user to
login via ssh to start an agent to temporarily store a
passphrase, and then the same user logs in separately
via ssh to make use of it, systemd treats them as
different user sessions, each with their own gpg-agent,
and the second one has no access to the passphrase
setup for it by the first one. Presumably, this isn't a
problem for most use cases, but it really spoiled
things for me.

cheers,
raf


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Management of background services with systemd [ In reply to ]
On Wed, 1 Mar 2023 21:24, Michael Richardson said:

> Combined with SSH access to the machine, and the passphrase/pin popup shows
> up in the wrong place.

Talking about ssh: Yes, you need to make sure that gpg-agent has been
launched. But once that has been done ssh works nicely.

The major problem with ssh is that ssh has no way to pass environment
variables to gpg-agent via the ssh-agent protocol. gpg-agent needs the
envvars to pop up pinentry on the right tty/display. I once posted
patches to the ssh list to extend ssh in this way but the interest was
not high and I had no time to starting convincing them to apply these
patches.

Actually it would also be possible to tell ssh to autostart gpg-agent,
similar to what gpg does. This could be done as a generic pre-connect
extension to ssh.


Shalom-Salam,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
Re: Management of background services with systemd [ In reply to ]
On Thu, Mar 02, 2023 at 05:53:21PM +0100, Werner Koch via Gnupg-users wrote:
> On Wed, 1 Mar 2023 21:24, Michael Richardson said:
>
> > Combined with SSH access to the machine, and the passphrase/pin popup shows
> > up in the wrong place.
>
> Talking about ssh: Yes, you need to make sure that gpg-agent has been
> launched. But once that has been done ssh works nicely.
>
> The major problem with ssh is that ssh has no way to pass environment
> variables to gpg-agent via the ssh-agent protocol. gpg-agent needs the
> envvars to pop up pinentry on the right tty/display. I once posted
> patches to the ssh list to extend ssh in this way but the interest was
> not high and I had no time to starting convincing them to apply these
> patches.
>
> Actually it would also be possible to tell ssh to autostart gpg-agent,
> similar to what gpg does. This could be done as a generic pre-connect
> extension to ssh.

FWIW, there is also the keychain tool that may be invoked in shell startup
scripts (which also provides the ability to differentiate - if needed -
between interactive and non-interactive shells):

- the tool itself: https://www.funtoo.org/Keychain
- a couple of patches that we apply to the Debian packaging:
- https://salsa.debian.org/debian/keychain/-/blob/debian/master/debian/patches/malformed-ssh-key.patch
- https://salsa.debian.org/debian/keychain/-/blob/debian/master/debian/patches/empty-ssh-askpass.patch

G'luck,
Peter

--
Peter Pentchev roam@ringlet.net roam@debian.org pp@storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13