Mehrere Login-Sessions auf einem Rechner: einen gemeinsamen gpg-agent oder pro Session einen eigenen?

Mathias Bauer mbauer at mailbox.org
Sa Dez 20 15:58:32 CET 2014 

Hallo Helmut,

da die E-Mails doch immer länger werden kürze ich mal etwas und
fasse zusammen:

* Helmut Waitzmann schrieb am Mo, 15. Dez 2014, um 02:32 (+0100):
> * Mathias Bauer <mbauer at mailbox.org> writes:
> > * Helmut Waitzmann schrieb am So, 14. Dez 2014, um 02:48 (+0100):
> > > * Mathias Bauer <mbauer at mailbox.org> writes:
> > > >
> > > > [gpg-agent (GnuPG) 2.0.19]
> > >
> > > [gpg-agent (GnuPG) 2.0.14 unter Debian/Linux]

[Doppelpunkte im Socket-Pfad und/oder -name]

> Momentan nicht.  Solange aber im gpg‐Manual nicht explizit
> steht, dass "${GNUPGHOME:-"${HOME}"/.gnupg}" keinen „:“
> enthalten darf, muss ich damit rechnen, dass eines Tages jemand
> auf die Idee kommt, in eine der Variablen HOME oder GNUPGHOME
> aus irgend einem Grund einen „:“ zu stecken.  Jeder
> Account‐Inhaber ist frei, etwa HOME umzusetzen und GNUPGHOME
> sowieso.  Und dann ergibt sich die Frage: Wie wird
> "${GNUPGHOME:-"${HOME}"/.gnupg}"/S.gpg-agent:12345:1
> interpretiert, wenn darin mehr als 2 „:“ enthalten sind?
>
> > [Start von gpg-agent mit --use-standard-socket, NFS]
>
> Genau.  Und leider ist es auch nicht möglich, das Socket per
> symbolic link oder gpg‐Konfiguration auf ein lokales
> Dateisystem umzusetzen, wenn „--use-standard-socket“ verwendet
> werden soll.  Dann scheidet „--use-standard-socket“ wohl aus...

1. Teilproblem:

Ja.  Da wegen des per NFS ausgelagerten HOME --use-standard-socket
nicht in Frage kommt, kann der Socket *nie* unterhalb HOME
erstellt werden.  "Doppelpunktprobleme" treten *nicht* auf.

Jeder Rechner hat den Socket lokal in /tmp/gpg-XXXXXX/S.gpg-agent.

Letztlich ist der (gut lesbare) Quellcode ist relevant.  Dieses
Teilproblem ist damit erledigt.

> ...und damit auch, wenn es nicht noch andere Kniffe gibt, pro
> Rechner für alle Login‐Sessions eines Benutzers dasselbe
> gpg-agent zu verwenden, dessen Start ich gpg2 überlassen könnte
> und das ich nie beenden müsste.

2. Teilproblem:

Nein, Du musst den Plan, denselben gpg-agent für alle Sessions
(X, Konsole) eines Benutzers zu verwenden nicht aufgeben.

Wie bereits mehrmals erwähnt, kannst Du dir eine Lösung mit
--write-env-file bauen.  Entscheidend ist, dass die in dieser
Datei festgelegte Variable GPG_AGENT_INFO in allen Sessions zur
Verfügung steht.  Und zwar bei jeweiligen X- oder Konsolen-Login
möglichst früh.  Die Autostart-Mechanismen diverser
Desktop-Umgebungen sind dafür allerdings zu spät!

Der gpg-agent muss dann nur einmal gestartet werden und kann
danach mit allen weiteren Sessions geteilt werden.

> Ich gehe davon aus, dass es unmöglich ist, Umgebungsvariablen
> von einer Sitzung zu einer anderen zu übermitteln, richtig?.
> Dann erzwingt – so, wie ich das verstehe – ein gemeinsames
> gpg-agent für alle Sitzungen auf demselben Rechner, dass
> „--use-standard-socket“ verwendet wird, was aber wegen NFS‐HOME
> ausgeschlossen ist, richtig?

Nein, tut es nicht.  Die Option --use-standard-socket hatten wir
doch schon ausgeschlossen...

Hm, ich skizziere mal grob eine Lösung, die funktioniert:

- Du legst eine Datei fest, z. B. /tmp/gpg-agent-info; lokal per
  Rechner, nicht per NFS in HOME.

- Jeder Start von gpg-agent nutzt sie als Argument der Option
  --write-env-file, also so
  eval $(gpg-agent --daemon --sh --write-env-file "$FILE")

- Für Sessions auf der Konsole werden in ~/.bashrc Prüfungen
  eingebaut: Existiert $FILE?  Wenn nein, starte Agent.  Wenn ja,
  lese $FILE und prüfe ob mit den Angaben in $FILE ein Agent
  "erreichbar" ist.  Wenn nein, starte einen.

  Wenn X von der Konsole aus, etwa per startx, gestartet wird,
  sind diese X-Sessions damit auch erledigt.

- Für X-Sessions die per Login über einen Display-Manager (gdm,
  kdm, xdm, etc.) gestartet werden, werden ähnliche Prüfungen in
  ~/.xsessionrc eingebaut.  Diese Datei wird gelesen vom Skript
  /etc/X11/Xsession.d/40x11-common_xsessionrc.

- Eventuell müssen für den Start weitere Dateien in $HOME
  angepasst werden.  (Unter Debian wheezy eher unwahrscheinlich.)

Damit ist gesichert, dass bei jedem Sessionstart $FILE gelesen
und somit die Variable GPG_AGENT_INFO allen Prozessen dieser
Session zur Verfügung steht.  Also teilen sich *mehrere* Sessions
*einen* Agenten.

Damit ist auch dieses Teilproblem erledigt.

> > Wenn ja, kannst Du beide Probleme mit der Option
> > --write-env-file beheben.  Das wird sehr schnell sehr
> > umfangreich werden...
> >
> > Mein Rat: Beschränke Dich auf die Skripte des jeweiligen
> > Benutzers und lass die Finger von /etc/X11/Xsession.d/*

Ich möchte noch hinzufügen, dass bei parallelen Sessions (X und
Konsole, mehrerer Konsolen, Kombinationen) die oben umschriebenen
"Prüfungen" bereits den Start von gpg-agent sehr umfangreich
werden.  Von weitere Komplexität durch eine automatische
Beendigung des Agenten-Prozesses rate ich daher erstmal ab.

> [...]

[NFS beeinflusst das ganze Problem überhaupt nicht.]

> Wenn gpg2 (z.B. von Thunderbird aus) einen gpg-agent selber
> gestartet hat, wie kommt dann ein zweites gpg2, das
> anschließend (z.B. von Gnus/Emacs) gestartet wird, an die
> "${GPG_AGENT_INFO}"‐Daten des bereits gestarteten Agents heran?

gpg2 startet keinen Agenten, wenn es die Variable GPG_AGENT_INFO
und den dazugehörigen gpg-agent findet.  Wie das funktioniert,
habe ich oben skizziert.

> Oder gibt es die Möglichkeit, zu prüfen, ob bereits ein Agent
> läuft, damit man beim Sessionstart genau dann einen startet,
> wenn noch keiner läuft, um zu vermeiden, dass gpg2 selber einen
> startet?

Ja, die gibt es und der dazu nötige Shell-Code ist in meiner
ersten E-Mail dieses Threads enthalten: Ãœber die GPG_AGENT_INFO
erhältst Du die PID und mit der PID kannst du prüfen, ob
gpg-agent läuft.

> > Der Socket befindet sich immer auf dem jeweiligen Rechner in
> > /tmp [...] Du hast Recht, das Verzeichnis des Sockets ist
> > nicht fix.
>
> Um es zu finden, könnte man „--write-env-file“ verwenden und
> hat aber dann das Problem, dass die dort angegebene Datei für
> jeden Rechner an für ihn individueller, aber fester, Stelle
> sein muss, weil auf jedem Rechner ein eigenes gpg-agent laufen
> muss und daher eine eigene solche Datei benötigt wird.

Auch das war bereits Inhalt meiner ersten beiden E-Mails: in der
ersten habe ich es angedeutet und in der zweiten etwas
ausführlicher beschrieben.  Ich glaube, wir bewegen uns im
Kreis...

> In der Datei "${GNUPGHOME:-"${HOME}"/.gnupg}"/gpg-agent.conf
> müsste dann auf jedem Rechner, der diese Datei per NFS erhält,
> beim Option
>
>    write-env-file FILE
>
> für „FILE“ ein Dateiname stehen, der entweder in einem lokalen
> Dateisystem liegt oder – wenn im NFS enthalten – den
> Rechnernamen enthält.

1. FILE macht man lokal in /tmp

2. write-env-file beim Start von gpg-agent angeben, nicht in
   der Konfigurationsdatei

> > oder Du prüfst beim Start jeder Session, ob bereits ein
> > Socket läuft
>
> Wie?

siehe erste E-Mail; siehe oben.

> Allen Login‐Vorgängen, egal, ob per login/getty oder Xsession,
> ist gemeinsam, dass ein Login‐Shell gestartet wird.

Nein, das ist falsch.

> Wäre damit "${HOME}"/.profile nicht ein möglicher Startpunkt?

Bei X-Sessions, die über einen Display-Manager gestartet werden,
wird ~/.profile ignoriert (auf Debian-Systemen).  Probiere es mit
einem

touch $HOME/profile-gelesen-$$

in ~/.profile aus.  Achte darauf, dass nicht eine nachfolgende
Shell unter X als Login-Shell gestartet wird.

> > > Kann ich daran, ob das in "${GPG_AGENT_INFO%:*:*}" genannte
> > > Socket vorhanden ist, sehen, ob ein gpg-agent läuft?

Das ist ein Teil der "Prüfungen".  Der gpg-agent könnte auch
irgendwie "verstorben" sein, ohne seinen Socket entfernen zu
können...

> > Ich beende hier weder unter X noch auf der Konsole den
> > Agenten automatisch.  Wenn man alle relevanten Möglichkeiten
> > ausfallsicher abdecken möchte, ist das Starten dieses einen
> > Agenten ausreichend umfangreich...
>
> D.h., du verwendest für alle Sessions, die du auf einem Rechner
> startest, einen gemeinsamen Agenten?

Ja.

> Wie findest du heraus, ob er bereits läuft, wenn du ein Session
> startest?

Mit den oben skizzierten Prüfungen.  Nochmal: wir bewegen uns im
Kreis.  Mir scheint, Du hast möglicherweise den Umfang des
Problems noch gar nicht richtig erfasst, denn...

> > Du bist Dir im Klaren darüber, dass das u. U. tiefgreifende
> > Änderungen im (Linux-)System erfordert?
>
> Das möchte ich nach Möglichkeit vermeiden.

...nur für den Start des Agenten und nur um die meisten (nicht
einmal alle!) Problemfälle zu prüfen und ggf. abzufangen, sind in
meinem Setup in ~/.bashrc und ~/.xsessionrc jeweils ca. 150
Zeilen Shell-Code nötig und viel(!) Zeit bei Analyse und Tests.

Wenn Du konkrete Fragen hast, versuche ich sie zu beantworten.
Eine Komplettlösung für lau wird es von mir jedoch nicht geben -
trotz Weihnachten!

Viele Grüße
Mathias

-- 
CAcert Assurer - See http://www.CAcert.org for details or ask me
GnuPG/OpenPGP: B100 5DC4 9686 BE64 87E9 0E22 44C3 983F A762 9DE8
-------------- n�chster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 760 bytes
Beschreibung: nicht verfügbar
URL         : </pipermail/attachments/20141220/9d070f78/attachment.sig>

Mehr Informationen über die Mailingliste Gnupg-de