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

[Helmut Waitzmann]

Mathias Bauer <mbauer at mailbox.org> writes:
> * 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]
>
> 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.  
> 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.

Wie garantierst du, dass diese Datei dem Benutzer gehört, der gerade ein
gpg-agent starten will?  In /tmp kann jeder Benutzer Dateien mit
beliebigen Dateinamen anlegen.  Und gerade beim gpg-agent wäre ein
Kuckucksei absolut tödlich für die Sicherheit.

> - 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")

Hat gpg-agent Vorkehrungen gegen Race‐Conditions?  Der Textabschnitt aus
dem gpg-agent‐Manual (dort zwar mit "${HOME}" statt /tmp)

        gpg-agent --daemon --enable-ssh-support \
                  --write-env-file "${HOME}/.gpg-agent-info"

   This code should only be run once per user session to initially fire
   up the agent.  In the example the optional support for the included
   Secure Shell agent is enabled and the information about the agent is
   written to a file in the HOME directory.  Note that by running
   gpg-agent without arguments you may test whether an agent is already
   running; however such a test may lead to a race condition, thus it is
   not suggested.

legt nahe, dass es keine verlässliche Möglichkeit gibt, Race‐Conditions
durch (nahezu) gleichzeitigen Start mehrerer Sessions zu vermeiden:
gpg-agent ohne Parameter zu starten, um zu testen, ob er bereits läuft,
scheidet damit aus.  Auch steht im Manual nichts davon, dass der Agent
die mit --write-env-file angegebene Datei gegen gleichzeitige
Schreibzugriffe sperrt und dass er, falls er die Datei bereits gesperrt
vorfindet, sich einfach beendet.

> - Für Sessions auf der Konsole werden in ~/.bashrc Prüfungen
>   eingebaut: Existiert $FILE?  Wenn nein, starte Agent.  

Wie bekommt man das race‐condition‐frei hin?

> Wenn ja, lese $FILE und prüfe ob mit den Angaben in $FILE ein Agent
> "erreichbar" ist.  Wenn nein, starte einen.

Wie verhindert man, dass, während ein Session "$FILE" gerade liest, ein
zweites "$FILE" gerade beschreibt?

Wie verhindert man, dass bei zwei Sessions der Test, ob bereits ein
Agent läuft, negativ ausfällt, und deshalb jedes der beiden Sessions
einen Agenten startet?

Für die Lösung des gpg-agent‐Problems brauche ich entweder die
Möglichkeit, einen gemeinsamen Agenten für alle Sessions eines Benutzers
auf demselben Rechner race‐condition‐frei zu starten oder einen eigenen Agenten
für jede Sitzung race‐condition‐frei zu beenden.

> 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!

Eine Komplettlösung brauche ich nicht.  Die Beantwortung der oben
angeführten Fragen reichen.