From nn.throttle at xoxy.net Fri Dec 12 20:18:27 2014 From: nn.throttle at xoxy.net (Helmut Waitzmann) Date: Fri, 12 Dec 2014 20:18:27 +0100 Subject: Wie kann ich dem ssh-agent mitteilen, dass er sich beenden soll? Message-ID: <87fvcksmlf.fsf@helmutwaitzmann.news.arcor.de> Starten kann ich den gpg-agent mittels $ eval $(gpg-agent --daemon) Dadurch erhalte ich die Umgebungsvariable GPG_AGENT_INFO. Wie beende ich den gpg-agent? Kann mir da der gpg-connect-agent helfen und, wenn ja, wie? Laut Dokumentation kann man dem gpg-agent zum Beenden ein INT‐ oder TERM‐Signal schicken. Aber wie komme ich verlässlich an die Prozessnummer des Agents heran? „Verlässlich“ heißt: Auch im Fall, dass der Agent abgestürzt ist und bereits ein anderer, unbeteiligter Prozess gestartet wurde, der zufällig seine Prozessnummer erhalten hat, muss sichergestellt werden können, dass dann nicht fälschlicherweise dem anderen Prozess ein TERM‐Signal geschickt wird. Weiß jemand Rat? From mbauer at mailbox.org Sat Dec 13 11:31:35 2014 From: mbauer at mailbox.org (Mathias Bauer) Date: Sat, 13 Dec 2014 11:31:35 +0100 Subject: Wie kann ich dem ssh-agent mitteilen, dass er sich beenden soll? In-Reply-To: <87fvcksmlf.fsf@helmutwaitzmann.news.arcor.de> References: <87fvcksmlf.fsf@helmutwaitzmann.news.arcor.de> Message-ID: <20141213103135.GA3459@mailbox.org> Hallo Helmut, * Helmut Waitzmann schrieb am Fr, 12. Dez 2014, um 20:18 (+0100): hier läuft $ gpg-agent --version gpg-agent (GnuPG) 2.0.19 > Wie beende ich den gpg-agent? Kann mir da der > gpg-connect-agent helfen und, wenn ja, wie? Nein. > Laut Dokumentation kann man dem gpg-agent zum Beenden ein INT‐ > oder TERM‐Signal schicken. Aber wie komme ich verlässlich an > die Prozessnummer des Agents heran? Ein TERM beendet den Agenten; bei drei TERMs oder einem INT geschieht das sofort (ohne Rücksicht auf Verluste). Die Prozessnummer ist Teil von GPG_AGENT_INFO: /path/to/socket/S.gpg-agent:12345:1 Mit einigen (POSIX-)Shell-Kommandos erhält man: P="${GPG_AGENT_INFO#*:}" P="${P%:*}" > „Verlässlich“ heißt: Auch im Fall, dass der Agent abgestürzt > ist und bereits ein anderer, unbeteiligter Prozess gestartet > wurde, der zufällig seine Prozessnummer erhalten hat, muss > sichergestellt werden können, dass dann nicht fälschlicherweise > dem anderen Prozess ein TERM‐Signal geschickt wird. Kurz: Steckt hinter P wirklich der Agent? Das ist jetzt nicht mehr ganz so lustig: if [ -n "$P" ] && \ [ -d "/proc/$P" ] && \ [ "x$(/bin/readlink "/proc/$P/exe")" = x/usr/bin/gpg-agent ] then kill -TERM "$P" sleep 2 kill -0 "$P" >/dev/null 2>&1 && kill -INT "$P" sleep 1 kill -0 "$P" >/dev/null 2>&1 && kill -KILL "$P" fi Erklärung: *Wenn* es (a) ein P gibt und (b) einen Prozess dazu und (c) dessen auführbare Datei mit dem Pfad zum Agent-Programm übereinstimmt, *dann* beende den Agent freundlich und warte. Wenn er danach immer noch da ist, beende ihn "unfreundlich". Diese Prüfung ist zwar immer noch offen für Race conditions, aber doch etwas sicherer. Man kann das noch beliebig(!) ausbauen: Behandlung von GPG_AGENT_INFO, Agent mit --write-env-file starten,... Natürlich kannst Du auch einfach mit killall -v -TERM gpg-agent alle Agenten grob beenden. Aber das empfehle ich nicht pauschal. > Weiß jemand Rat? Das ganze Vorgehen ist abhängig davon, wie Deine Sessions gestartet werden, ob Konsole und/oder X, ob mehrere parallel, etc. Ich hoffe, die obigen Schritte helfen Dir erst einmal weiter. Gruß, 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 : From nn.throttle at xoxy.net Sun Dec 14 02:48:24 2014 From: nn.throttle at xoxy.net (Helmut Waitzmann) Date: Sun, 14 Dec 2014 02:48:24 +0100 Subject: Wie kann ich dem ssh-agent mitteilen, dass er sich beenden soll? References: <87fvcksmlf.fsf@helmutwaitzmann.news.arcor.de> <20141213103135.GA3459@mailbox.org> Message-ID: <8761dfrofy.fsf@helmutwaitzmann.news.arcor.de> Mathias Bauer writes: > Hallo Helmut, > > * Helmut Waitzmann schrieb am Fr, 12. Dez 2014, um 20:18 (+0100): > > hier läuft > $ gpg-agent --version > gpg-agent (GnuPG) 2.0.19 > Bei mir ist es $ gpg-agent --version gpg-agent (GnuPG) 2.0.14 libgcrypt 1.4.5 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. > Ein TERM beendet den Agenten; bei drei TERMs oder einem INT > geschieht das sofort (ohne Rücksicht auf Verluste). Die > Prozessnummer ist Teil von GPG_AGENT_INFO: > /path/to/socket/S.gpg-agent:12345:1 > > Mit einigen (POSIX-)Shell-Kommandos erhält man: > > P="${GPG_AGENT_INFO#*:}" > P="${P%:*}" Ah ja, also 3 Teile, getrennt mit je einem „:“. Vermutet habe ich das auch, konnte aber in der Dokumentation keinen Hinweis finden, ob es immer (d.h. auch in Zukunft) genau 3 Teile sind, und auch nicht, was geschieht, wenn im Socketnamen ein Doppelpunkt enthalten ist. Mein ssh-agent weigert sich, das Socket anzulegen, wenn ich ihm das Option „--use-standard-socket“ mitgebe und GNUPGHOME einen „:“ enthält. Soweit also keine Gefahr für mehr als 2 „:“ in GPG_AGENT_INFO. Nur das Handbuch schweigt halt dazu. > >> „Verlässlich“ heißt: Auch im Fall, dass der Agent abgestürzt >> ist und bereits ein anderer, unbeteiligter Prozess gestartet >> wurde, der zufällig seine Prozessnummer erhalten hat, muss >> sichergestellt werden können, dass dann nicht fälschlicherweise >> dem anderen Prozess ein TERM‐Signal geschickt wird. > > Kurz: Steckt hinter P wirklich der Agent? Das ist jetzt nicht > mehr ganz so lustig: > > if [ -n "$P" ] && \ > [ -d "/proc/$P" ] && \ > [ "x$(/bin/readlink "/proc/$P/exe")" = x/usr/bin/gpg-agent ] > then > kill -TERM "$P" > sleep 2 > kill -0 "$P" >/dev/null 2>&1 && kill -INT "$P" > sleep 1 > kill -0 "$P" >/dev/null 2>&1 && kill -KILL "$P" > fi > > Erklärung: *Wenn* es (a) ein P gibt und (b) einen Prozess dazu > und (c) dessen auführbare Datei mit dem Pfad zum Agent-Programm > übereinstimmt, *dann* beende den Agent freundlich und warte. > Wenn er danach immer noch da ist, beende ihn "unfreundlich". > > Diese Prüfung ist zwar immer noch offen für Race conditions, aber > doch etwas sicherer. Ja, danke, verstanden. Ich hatte gehofft, dass da vielleicht der gpg-connect-agent helfen könnte, den gpg-agent zu finden, oder – noch besser – ihm zu sagen, er solle sich beenden. Schade, das das nicht geht. > Behandlung von GPG_AGENT_INFO, Agent mit --write-env-file > starten,... > Natürlich kannst Du auch einfach mit > > killall -v -TERM gpg-agent > > alle Agenten grob beenden. Aber das empfehle ich nicht pauschal. Mir ist da auch nicht wohl dabei. > Das ganze Vorgehen ist abhängig davon, wie Deine Sessions > gestartet werden, ob Konsole und/oder X, ob mehrere parallel, > etc. Einen gpg-agent möchte ich bei jedem Einloggen zur Verfügung haben, egal, ob auf der Konsole oder mit X11. Ich hätte nichts dagegen, wenn es machbar wäre, auf jedem Rechner, der das gemeinsame NFS‐HOME‐Verzeichnis nutzt, nur einen gpg-agent für alle Sessions zu nutzen. Das hätte den Vorteil, dass ich diesen einen gpg-agent nicht beenden muss: Er soll ja sowieso für alle weitere Sessions (egal, ob augenblickliche oder zukünftige) verwendet werden. Das bedeutet aber, dass ich beim Einloggen nicht einfach einen gpg-agent starten kann, denn es könnte ja bereits einer laufen. Deswegen kann dann der Fall eintreten (wenn doch noch kein gpg-agent läuft), dass gpg2 selber einen startet. Weil ich dabei aber keine Möglichkeit habe, "${GPG_AGENT_INFO}" an andere bereits laufende Prozesse (etwa ein Mailerprogramm) weiterzugeben, müsste das Socket des von gpg2 gestarteten gpg-agents dann immer an derselben Stelle im Dateisystem zu finden sein, ich müsste also in gpg-agents Konfigurationsdatei „use-standard-socket“ vermerken. Das aber ist laut Dokumentation nicht erlaubt, wenn "${GNUPGHOME-"${HOME}/.gnupg"}" vom NFS kommt. Also bleibt wohl nur die Vorgehensweise „für jedes Login‐Session einen eigenen gpg-agent“: Weil dabei bei jedem Login in jedem Fall ein gpg-agent gestartet wird, kann die von ihm herausgegebene Umgebungsvariable GPG_AGENT_INFO einfach an alle weiteren Prozesse des Sessions vererbt werden und es entsteht auch nicht das Problem, dass gpg2 selber einen gpg-agent startet. Ah, da tauchen noch ein paar Fragen auf: Ich habe durch Ausprobieren festgestellt: Die mit dem Option „--write-env-file“ vom Agent erzeugte Umgebungsvariablen‐Datei wird weder geleert noch entfernt, wenn sich der Agent nach Empfang eines TERM‐Signals beendet. Das Socket aber wird entfernt. Kann ich daran, ob das in "${GPG_AGENT_INFO%:*:*}" genannte Socket vorhanden ist, sehen, ob ein gpg-agent läuft? Dann könnte ich das als weiteres notwendiges Kriterium nutzen, ehe ich beim Ausloggen ein TERM‐Signal in Richtung gpg-agent schicke. Aber auch hier gäbe es dasselbe Race‐Condition wie oben. Wird die vom Agent mit Option „--write-env-file“ erzeugte Umgebungsvariablen‐Datei von gpg2, gpg-connect-agent oder gpg-agent gelesen oder ist sie nur eine Alternative zu $ eval "$(gpg-agent --daemon)" ? > Ich hoffe, die obigen Schritte helfen Dir erst einmal weiter. Ja, das tun sie. Vielen Dank. Grüße, Helmut From mbauer at mailbox.org Sun Dec 14 19:55:16 2014 From: mbauer at mailbox.org (Mathias Bauer) Date: Sun, 14 Dec 2014 19:55:16 +0100 Subject: Wie kann ich dem ssh-agent mitteilen, dass er sich beenden soll? In-Reply-To: <8761dfrofy.fsf@helmutwaitzmann.news.arcor.de> References: <87fvcksmlf.fsf@helmutwaitzmann.news.arcor.de> <20141213103135.GA3459@mailbox.org> <8761dfrofy.fsf@helmutwaitzmann.news.arcor.de> Message-ID: <20141214185515.GA20887@mailbox.org> * Helmut Waitzmann schrieb am So, 14. Dez 2014, um 02:48 (+0100): > Mathias Bauer writes: > > > * Helmut Waitzmann schrieb am Fr, 12. Dez 2014, um 20:18 (+0100): > > > > hier läuft > > $ gpg-agent --version > > gpg-agent (GnuPG) 2.0.19 > > Bei mir ist es > $ gpg-agent --version > gpg-agent (GnuPG) 2.0.14 > > > Ein TERM beendet den Agenten; bei drei TERMs oder einem INT > > geschieht das sofort (ohne Rücksicht auf Verluste). Die > > Prozessnummer ist Teil von GPG_AGENT_INFO: > > /path/to/socket/S.gpg-agent:12345:1 > > [...] und auch nicht, was geschieht, wenn im Socketnamen ein > Doppelpunkt enthalten ist. Was meinst Du damit? Den Namen des Sockets, S.gpg-agent, kannst Du nicht vorgeben und er enthält auch nie einen Doppelpunkt. > Mein ssh-agent weigert sich, das Socket anzulegen, wenn ich ihm > das Option „--use-standard-socket“ mitgebe und GNUPGHOME einen > „:“ enthält. Soweit also keine Gefahr für mehr als 2 „:“ in > GPG_AGENT_INFO. Nur das Handbuch schweigt halt dazu. Ich ordne mal ein wenig: - Du verwendest einen separaten SSH-Agenten und *nicht* gpg-agent mit der Option --enable-ssh-support. - Was der SSH-Agent macht oder nicht, lassen wir jetzt erstmal außen vor. Wo kommen bei Dir denn Doppelpunkte in Pfaden oder Namen vor? Welches OS/Distribution verwendest Du denn? Startet man den gpg-agent mit der Option --use-standard-socket, erhält man GPG_AGENT_INFO=/home/you/.gnupg/S.gpg-agent:12345:1 Das kann man *nicht* machen, wenn das HOME-Verzeichnis per NFS importiert wird, was auch so dokumentiert ist: This option may not be used if the home directory is mounted on a remote file system... > > Das ganze Vorgehen ist abhängig davon, wie Deine Sessions > > gestartet werden, ob Konsole und/oder X, ob mehrere parallel, > > etc. > > Einen gpg-agent möchte ich bei jedem Einloggen zur Verfügung > haben, egal, ob auf der Konsole oder mit X11. Das funktioniert und ist auch kein Problem. Starte einfach bei jeder Anmeldung einen neuen Agenten. Schwierig wird es in den beiden folgenden Situationen: - Es soll ein und derselbe Agenten benutzt werden. - Für mehrere, auch parallel benutzte X- oder Konsole-Sessions soll der Agent der *ersten* gestarteten Session für alle anderen ebenfalls verwendet werden. Da muss man ganz genau analysieren an welcher Stelle, X und Konsole, der Agent jeweils gestartet wird, wo die Environment-Variablen wirken, etc. und das Ganze dann entsprechend modifizieren. Du bist Dir im Klaren darüber, dass das u. U. tiefgreifende Änderungen im (Linux-)System erfordert? 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/* - wenn Du Linux verwendest. Das geht und ist umfangreich genug. Ich habe eine solche Lösung hier am Laufen. > Ich hätte nichts dagegen, wenn es machbar wäre, auf jedem > Rechner, der das gemeinsame NFS‐HOME‐Verzeichnis nutzt, nur > einen gpg-agent für alle Sessions zu nutzen. Auf jedem Rechner jeweils pro Benutzer für alle Sessions jeweils nur einen Agenten zu verwenden funktioniert. NFS hat damit nichts zu tun. > Das hätte den Vorteil, dass ich diesen einen gpg-agent nicht > beenden muss: Er soll ja sowieso für alle weitere Sessions > (egal, ob augenblickliche oder zukünftige) verwendet werden. > Das bedeutet aber, dass ich beim Einloggen nicht einfach einen > gpg-agent starten kann, denn es könnte ja bereits einer laufen. Ja. > Deswegen kann dann der Fall eintreten (wenn doch noch kein > gpg-agent läuft), dass gpg2 selber einen startet. Weil ich > dabei aber keine Möglichkeit habe, "${GPG_AGENT_INFO}" an > andere bereits laufende Prozesse (etwa ein Mailerprogramm) > weiterzugeben, Doch, die hast Du, wenn Du früh genug in den Sessions eingreifst. > müsste das Socket des von gpg2 gestarteten gpg-agents dann > immer an derselben Stelle im Dateisystem zu finden sein, Der Socket befindet sich immer auf dem jeweiligen Rechner in /tmp, nicht irgendwo per NFS. (Ausnahme: --use-standard-socket) Du hast Recht, das Verzeichnis des Sockets ist nicht fix. Hier z. B. gerade /tmp/gpg-y5srdG/S.gpg-agent:12345:1 > ich müsste also in gpg-agents Konfigurationsdatei > „use-standard-socket“ vermerken. Das aber ist laut > Dokumentation nicht erlaubt, wenn > "${GNUPGHOME-"${HOME}/.gnupg"}" vom NFS kommt. Genau, und das macht auch Sinn so. Sockets bleiben lokal. > Also bleibt wohl nur die Vorgehensweise „für jedes > Login‐Session einen eigenen gpg-agent“: Weil dabei bei jedem > Login in jedem Fall ein gpg-agent gestartet wird, kann die von > ihm herausgegebene Umgebungsvariable GPG_AGENT_INFO einfach an > alle weiteren Prozesse des Sessions vererbt werden und es > entsteht auch nicht das Problem, dass gpg2 selber einen > gpg-agent startet. Entweder so (Du hast dann mehrere Agenten) oder Du prüfst beim Start jeder Session, ob bereits ein Socket läuft und startetst ggf. einen neuen mit der Option --write-env-file. Wie schon oben angedeutet, ist diese Prüfung des springende Punkt. Dafür musst man an mehreren Stellen des Startprozeders (Shell-Skripte!) eingreifen. Das ist sehr umfangreich und etwas kompliziert, funktioniert jedoch. > Ich habe durch Ausprobieren festgestellt: Die mit dem Option > „--write-env-file“ vom Agent erzeugte Umgebungsvariablen‐Datei > wird weder geleert noch entfernt, wenn sich der Agent nach > Empfang eines TERM‐Signals beendet. Das Socket aber wird > entfernt. > > Kann ich daran, ob das in "${GPG_AGENT_INFO%:*:*}" genannte > Socket vorhanden ist, sehen, ob ein gpg-agent läuft? Ja, mit zusätzlichen Prüfungen wie meiner letzten E-Mail erwähnt. Die genügen für das XXL-Szenario (mehrere Sessions, parallel, etc.) natürlich nicht. > Dann könnte ich das als weiteres notwendiges Kriterium nutzen, > ehe ich beim Ausloggen ein TERM‐Signal in Richtung gpg-agent > schicke. Aber auch hier gäbe es dasselbe Race‐Condition wie > oben. 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... > Wird die vom Agent mit Option „--write-env-file“ erzeugte > Umgebungsvariablen‐Datei von gpg2, gpg-connect-agent oder > gpg-agent gelesen oder ist sie nur eine Alternative zu > > $ eval "$(gpg-agent --daemon)" Diese Datei, deren Ort Du vorgibst, wird von niemandem gefunden und daher auch nicht automatisch gelesen. Du kannst sie selbst z. B. in Startskripten des Benutzers für X- und Konsole-Sessions verwenden. 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 : From nn.throttle at xoxy.net Mon Dec 15 02:32:13 2014 From: nn.throttle at xoxy.net (Helmut Waitzmann) Date: Mon, 15 Dec 2014 02:32:13 +0100 Subject: Mehrere Login-Sessions auf einem Rechner: einen gemeinsamen gpg-agent oder pro Session einen eigenen? (was: Wie kann ich dem ssh-agent mitteilen, dass er sich beenden soll?) References: <87fvcksmlf.fsf@helmutwaitzmann.news.arcor.de> <20141213103135.GA3459@mailbox.org> <8761dfrofy.fsf@helmutwaitzmann.news.arcor.de> <20141214185515.GA20887@mailbox.org> Message-ID: <87388hsnnt.fsf_-_@helmutwaitzmann.news.arcor.de> Mathias Bauer writes: > * Helmut Waitzmann schrieb am So, 14. Dez 2014, um 02:48 (+0100): > >> Mathias Bauer writes: >> >> > * Helmut Waitzmann schrieb am Fr, 12. Dez 2014, um 20:18 (+0100): >> > >> > hier läuft >> > $ gpg-agent --version >> > gpg-agent (GnuPG) 2.0.19 >> >> Bei mir ist es >> $ gpg-agent --version >> gpg-agent (GnuPG) 2.0.14 >> >> > Ein TERM beendet den Agenten; bei drei TERMs oder einem INT >> > geschieht das sofort (ohne Rücksicht auf Verluste). Die >> > Prozessnummer ist Teil von GPG_AGENT_INFO: >> > /path/to/socket/S.gpg-agent:12345:1 >> >> [...] und auch nicht, was geschieht, wenn im Socketnamen ein >> Doppelpunkt enthalten ist. > > Was meinst Du damit? Mit Socketnamen meinte ich „/path/to/socket/S.gpg-agent“, nicht nur die Komponente nach dem letzten „/“. > Den Namen des Sockets, S.gpg-agent, kannst Du nicht vorgeben und er > enthält auch nie einen Doppelpunkt. Ja, ist mir klar. "${GNUPGHOME:-"${HOME}"/.gnupg}" kann aber Doppelpunkte enthalten. >> Mein ssh-agent weigert sich, das Socket anzulegen, wenn ich ihm >> das Option „--use-standard-socket“ mitgebe und GNUPGHOME einen >> „:“ enthält. Soweit also keine Gefahr für mehr als 2 „:“ in >> GPG_AGENT_INFO. Nur das Handbuch schweigt halt dazu. > > Ich ordne mal ein wenig: > - Du verwendest einen separaten SSH-Agenten und *nicht* gpg-agent > mit der Option --enable-ssh-support. > - Was der SSH-Agent macht oder nicht, lassen wir jetzt erstmal > außen vor. Autsch! Das war ein Fehler von mir, habe ich doch tatsächlich „ssh-agent“ geschrieben, aber „gpg-agent“ gemeint. Keine Ahnung, wie ich dazu kam, wahrscheinlich, weil im gpg-agent‐Manual auch vom ssh-agent die Rede ist. Ich bitte um Verzeihung für die Verwirrung, die ich gestiftet habe. (Mir ist klar, dass man den gpg-agent auch die Dienste des ssh-agent übernehmen lassen kann, wenn man --enable-ssh-support verwendet. Das habe ich aber nicht vor.) > Wo kommen bei Dir denn Doppelpunkte in Pfaden oder Namen vor? 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? > Welches OS/Distribution verwendest Du denn? Debian/Linux > Startet man den gpg-agent mit der Option --use-standard-socket, erhält > man > > GPG_AGENT_INFO=/home/you/.gnupg/S.gpg-agent:12345:1 > > Das kann man *nicht* machen, wenn das HOME-Verzeichnis per NFS > importiert wird, was auch so dokumentiert ist: > > This option may not be used if the home directory is mounted > on a remote file system... 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 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. >> > Das ganze Vorgehen ist abhängig davon, wie Deine Sessions >> > gestartet werden, ob Konsole und/oder X, ob mehrere parallel, >> > etc. >> >> Einen gpg-agent möchte ich bei jedem Einloggen zur Verfügung >> haben, egal, ob auf der Konsole oder mit X11. > > Das funktioniert und ist auch kein Problem. Starte einfach bei > jeder Anmeldung einen neuen Agenten. Schwierig wird es in den > beiden folgenden Situationen: > > - Es soll ein und derselbe Agenten benutzt werden. > > - Für mehrere, auch parallel benutzte X- oder Konsole-Sessions > soll der Agent der *ersten* gestarteten Session für alle > anderen ebenfalls verwendet werden. > > Da muss man ganz genau analysieren an welcher Stelle, X und > Konsole, der Agent jeweils gestartet wird, wo die > Environment-Variablen wirken, etc. und das Ganze dann > entsprechend modifizieren. 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? > 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. > 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/* - wenn Du > Linux verwendest. Das sowieso. gpg-Konfiguration sollte Benutzersache sein und deshalb unter "${HOME}", nicht unter /etc stattfinden. >> Ich hätte nichts dagegen, wenn es machbar wäre, auf jedem >> Rechner, der das gemeinsame NFS‐HOME‐Verzeichnis nutzt, nur >> einen gpg-agent für alle Sessions zu nutzen. > > Auf jedem Rechner jeweils pro Benutzer für alle Sessions jeweils > nur einen Agenten zu verwenden funktioniert. Da wäre ich an Einzelheiten interessiert. > NFS hat damit nichts zu tun. NFS verbietet nur ein einfaches „--use-standard-socket“. >> Das hätte den Vorteil, dass ich diesen einen gpg-agent nicht >> beenden muss: Er soll ja sowieso für alle weitere Sessions >> (egal, ob augenblickliche oder zukünftige) verwendet werden. >> Das bedeutet aber, dass ich beim Einloggen nicht einfach einen >> gpg-agent starten kann, denn es könnte ja bereits einer laufen. > > Ja. > >> Deswegen kann dann der Fall eintreten (wenn doch noch kein >> gpg-agent läuft), dass gpg2 selber einen startet. Weil ich >> dabei aber keine Möglichkeit habe, "${GPG_AGENT_INFO}" an >> andere bereits laufende Prozesse (etwa ein Mailerprogramm) >> weiterzugeben, > > Doch, die hast Du, wenn Du früh genug in den Sessions eingreifst. 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? 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? Der Hinweis im Manual 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 mir nahe, das sei nicht möglich. >> müsste das Socket des von gpg2 gestarteten gpg-agents dann >> immer an derselben Stelle im Dateisystem zu finden sein, > > Der Socket befindet sich immer auf dem jeweiligen Rechner in > /tmp, nicht irgendwo per NFS. (Ausnahme: --use-standard-socket) > 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. 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. Können in "${GNUPGHOME:-"${HOME}"/.gnupg}"/gpg-agent.conf Umgebungsvariable verwendet werden? Ich habe dazu im Manual nichts gefunden. >> Also bleibt wohl nur die Vorgehensweise „für jedes >> Login‐Session einen eigenen gpg-agent“: Weil dabei bei jedem >> Login in jedem Fall ein gpg-agent gestartet wird, kann die von >> ihm herausgegebene Umgebungsvariable GPG_AGENT_INFO einfach an >> alle weiteren Prozesse des Sessions vererbt werden und es >> entsteht auch nicht das Problem, dass gpg2 selber einen >> gpg-agent startet. > > Entweder so (Du hast dann mehrere Agenten) und das Problem, die Agenten nicht vollständig race‐condition‐frei beenden zu können > oder Du prüfst beim Start jeder Session, ob bereits ein Socket läuft Wie? > und startetst ggf. einen neuen mit der Option --write-env-file. > > Wie schon oben angedeutet, ist diese Prüfung des springende > Punkt. Dafür musst man an mehreren Stellen des Startprozeders > (Shell-Skripte!) eingreifen. Allen Login‐Vorgängen, egal, ob per login/getty oder Xsession, ist gemeinsam, dass ein Login‐Shell gestartet wird. Wäre damit "${HOME}"/.profile nicht ein möglicher Startpunkt? >> Ich habe durch Ausprobieren festgestellt: Die mit dem Option >> „--write-env-file“ vom Agent erzeugte Umgebungsvariablen‐Datei >> wird weder geleert noch entfernt, wenn sich der Agent nach >> Empfang eines TERM‐Signals beendet. Das Socket aber wird >> entfernt. >> >> Kann ich daran, ob das in "${GPG_AGENT_INFO%:*:*}" genannte >> Socket vorhanden ist, sehen, ob ein gpg-agent läuft? > > Ja, mit zusätzlichen Prüfungen wie meiner letzten E-Mail erwähnt. > Die genügen für das XXL-Szenario (mehrere Sessions, parallel, > etc.) natürlich nicht. Traditionell sind mehrere Login‐Sessions in Unix kein Problem; auch X11 kommt damit zurecht. Das soll, wenn irgend möglich, auch mit gpg-agent nicht anders sein. Das bedeutet: Mehrere Sessions, die ich auf einem oder verschiedenen Rechnern mit gemeinsamem, per NFS importiertem, HOME‐Verzeichnis parallel starte, haben entweder pro Session oder pro Rechner einen eigenen Agenten. > 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? Wie findest du heraus, ob er bereits läuft, wenn du ein Session startest? Grüße, und vielen Dank für deine Mühe, Helmut From mbauer at mailbox.org Sat Dec 20 15:58:32 2014 From: mbauer at mailbox.org (Mathias Bauer) Date: Sat, 20 Dec 2014 15:58:32 +0100 Subject: Mehrere Login-Sessions auf einem Rechner: einen gemeinsamen gpg-agent oder pro Session einen eigenen? In-Reply-To: <87388hsnnt.fsf_-_@helmutwaitzmann.news.arcor.de> References: <87fvcksmlf.fsf@helmutwaitzmann.news.arcor.de> <20141213103135.GA3459@mailbox.org> <8761dfrofy.fsf@helmutwaitzmann.news.arcor.de> <20141214185515.GA20887@mailbox.org> <87388hsnnt.fsf_-_@helmutwaitzmann.news.arcor.de> Message-ID: <20141220145832.GA6290@mailbox.org> 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 writes: > > * Helmut Waitzmann schrieb am So, 14. Dez 2014, um 02:48 (+0100): > > > * Mathias Bauer 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 : From wk at gnupg.org Sat Dec 20 19:41:36 2014 From: wk at gnupg.org (Werner Koch) Date: Sat, 20 Dec 2014 19:41:36 +0100 Subject: Mehrere Login-Sessions auf einem Rechner: einen gemeinsamen gpg-agent oder pro Session einen eigenen? In-Reply-To: <20141220145832.GA6290@mailbox.org> (Mathias Bauer's message of "Sat, 20 Dec 2014 15:58:32 +0100") References: <87fvcksmlf.fsf@helmutwaitzmann.news.arcor.de> <20141213103135.GA3459@mailbox.org> <8761dfrofy.fsf@helmutwaitzmann.news.arcor.de> <20141214185515.GA20887@mailbox.org> <87388hsnnt.fsf_-_@helmutwaitzmann.news.arcor.de> <20141220145832.GA6290@mailbox.org> Message-ID: <87388aw4db.fsf@vigenere.g10code.de> On Sat, 20 Dec 2014 15:58, mbauer at mailbox.org said: > 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. FWIW, mit 2.1.1 (zusammen mit libassuan 2.2.0) ist das wieder möglich. Man legt hierzu eine einfache Textdatei unter dem Namen ~/.gnupg/S.gpg-agent an. Die hat dann z.B. diesen Aufbau: --8<---------------cut here---------------start------------->8--- %%Assuan%% socket=/var/run/${USER}/S.gpg-agent --8<---------------cut here---------------end--------------->8--- Der normale Socket wird damit umgeleitet auf /var/run/USERNAME/... wobei das Directory existieren sollte und man die notwendigen Rechte habe sollte. Man kann in der obigen Datei beliebige Environment Variabeln benutzten. Das kann man auch für S.gpg-agent.ssh und S.dirmngr machen. Die Datei am besten mittels printf anlegen und vorher eine etwaig existierende Socket-Datei mit rm löschen. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mbauer at mailbox.org Sun Dec 21 16:43:35 2014 From: mbauer at mailbox.org (Mathias Bauer) Date: Sun, 21 Dec 2014 16:43:35 +0100 Subject: Mehrere Login-Sessions auf einem Rechner: einen gemeinsamen gpg-agent oder pro Session einen eigenen? In-Reply-To: <87388aw4db.fsf@vigenere.g10code.de> References: <87fvcksmlf.fsf@helmutwaitzmann.news.arcor.de> <20141213103135.GA3459@mailbox.org> <8761dfrofy.fsf@helmutwaitzmann.news.arcor.de> <20141214185515.GA20887@mailbox.org> <87388hsnnt.fsf_-_@helmutwaitzmann.news.arcor.de> <20141220145832.GA6290@mailbox.org> <87388aw4db.fsf@vigenere.g10code.de> Message-ID: <20141221154335.GA32056@mailbox.org> Hallo Werner, * Werner Koch schrieb am Sa, 20. Dez 2014, um 19:41 (+0100): > On Sat, 20 Dec 2014 15:58, mbauer at mailbox.org said: > > Man legt hierzu eine einfache Textdatei unter dem Namen > ~/.gnupg/S.gpg-agent an. Die hat dann z.B. diesen Aufbau: > > --8<---------------cut here---------------start------------->8--- > %%Assuan%% > socket=/var/run/${USER}/S.gpg-agent > --8<---------------cut here---------------end--------------->8--- > > Der normale Socket wird damit umgeleitet auf > /var/run/USERNAME/... wobei das Directory existieren sollte > und man die notwendigen Rechte habe sollte. Man kann in der > obigen Datei beliebige Environment Variabeln benutzten. ah, sehr gut. Das vereinfach das Handling der Umgebungsvariablen deutlich. > Das kann man auch für S.gpg-agent.ssh und S.dirmngr machen. > Die Datei am besten mittels printf anlegen und vorher eine > etwaig existierende Socket-Datei mit rm löschen. Gute Idee! Die Details werde ich mir noch ansehen und testen. Bis zum (Produktiv-)Einsatz von 2.1.* dauert es hier noch etwas... 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 : From ml.throttle at xoxy.net Tue Dec 23 19:47:14 2014 From: ml.throttle at xoxy.net (Helmut Waitzmann) Date: Tue, 23 Dec 2014 19:47:14 +0100 Subject: Mehrere Login-Sessions auf einem Rechner: einen gemeinsamen gpg-agent oder pro Session einen eigenen? In-Reply-To: <20141220145832.GA6290@mailbox.org> (Mathias Bauer's message of "Sat, 20 Dec 2014 15:58:32 +0100") Message-ID: <871tnq4304.fsf@helmutwaitzmann.news.arcor.de> Mathias Bauer writes: > * Helmut Waitzmann schrieb am Mo, 15. Dez 2014, um 02:32 (+0100): >> * Mathias Bauer writes: >> > * Helmut Waitzmann schrieb am So, 14. Dez 2014, um 02:48 (+0100): >> > > * Mathias Bauer 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.