launching GnuPG daemons from the system session manager

Daniel Kahn Gillmor dkg at fifthhorseman.net
Wed Jul 13 15:30:35 CEST 2016


On Wed 2016-07-13 14:41:58 +0200, Neal H. Walfield wrote:
> I find it strange that gpg-agent is managed as part of the user's
> session when it is independent of the session.  Concretely, if I have
> multiple sessions open, e.g., desktop & multiple ssh instances, then I
> expect them all to share the same gpg-agent.  Also, I wonder if this
> doesn't negatively impact the use of --extra-socket.

You'll be happy to learn that this is exactly what systemd's --user
handling does, actually :) I think i was using the term "session"
loosely above, so let me try to be more specific.

In systemd, there is a "slice" allocated to each user, which contains
their user-specific systemd service process manager.  This slice
operates concurrently with every existing login session.  If there are
no login sessions, then the user's service management is terminated.  As
soon as the user's first session begins, the slice starts up the
services.

I might still be using the terms sloppily -- sorry!  Below is some
example structured output from "systemctl status" from my machine
"alice" that might make things clearer.  My user account is id 1234, and
i'm logged in via both an X11 login (session-13, triggered by "startx"
in this case) and on a second vt (session-449):

-------------
● alice
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Fri 2016-07-08 12:10:29 CEST; 5 days ago
   CGroup: /
           ├─init.scope
           │ └─1 /lib/systemd/systemd --switched-root --system --deserialize 23
           ├─system.slice
           │ ├─dbus.service
           │ │ └─2049 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
           │ ├─cron.service
           │ │ └─3592 /usr/sbin/cron -f
           │[…]
           │ └─smartd.service
           │   └─2061 /usr/sbin/smartd -n
           └─user.slice
             └─user-1234.slice
               ├─session-13.scope
               │ ├─ 2708 /bin/sh /usr/bin/startx
               │ ├─ 2758 xinit /etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -keeptty -auth /home/dkg/tmp/serverauth.QQfVGkGhWJ
               │ ├─ 2759 /usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth /home/dkg/tmp/serverauth.QQfVGkGhWJ
               │ ├─ 2790 /usr/bin/dbus-launch --exit-with-session --sh-syntax
               │ ├─ 2791 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
               │ ├─ 2818 /usr/bin/openbox --startup /usr/lib/x86_64-linux-gnu/openbox-autostart OPENBOX
               │[…]
               │ ├─31291 rxvt -geometry 80x26
               │ ├─31292 bash
               │ └─31308 systemctl status
               ├─user at 1234.service
               │ ├─gpg-agent.service
               │ │ └─2705 /usr/bin/gpg-agent --daemon --homedir /home/dkg/.gnupg
               │ ├─dirmngr.service
               │ │ └─18958 /usr/bin/dirmngr --daemon --homedir /home/dkg/.gnupg
               │ └─init.scope
               │   ├─2696 /lib/systemd/systemd --user
               │   └─2698 (sd-pam)                                                      
               └─session-449.scope
                 ├─ 2408 /bin/login --    
                 └─31401 -bash

-------------

As you can see, user at 1234.service is managed independently from
session-13.scope and session-449.scope.  when i terminate both sessions,
and if no other scopes exist in my user slice, then systemd should tear
down user at 1234.service and all its dependent services.

I end up with clean automated startup and safe automated teardown that
coincides with the times that i'm actually authenticated to the machine,
regardless of how many sessions i have running concurrently.

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


More information about the Gnupg-devel mailing list