GPG Kann keine Verbindung zu S.gpg-agent: Verbindung verweigert

stimmen
0

Ich versuche , GPG einzurichten voreingestellte Passwort - Caching der GPG - Agenten verwenden , damit ich meinen Dateiverschlüsselungsprozess automatisieren können. Damit das GPG-Agent ausgeführt werden und richtig die Passwort - Cache, so scheint es dort eine sein muss S.gpg-Agent Buchse innerhalb des ~ / .gnupg / Verzeichnis befinden , die im Stammverzeichnis erzeugt wird , wenn ich GPG einrichten und GPG-agent.

Was ich getan habe (und das schien in der Vergangenheit Arbeit) ist ich alles als root starten würde und kopieren Sie den Inhalt des /.gnupg Verzeichnisses meiner weniger privilegierten Benutzer und Berechtigungen erteilen zu diesem Socket und Verzeichnis für den Benutzer. Die Befehle, die ich lief den GPG-Agenten-Daemon und Cache-Passwort zu starten:

gpg-agent --homedir /home/<user>/.gnupg --daemon
/usr/libexec/gpg-preset-passphrase --preset --passphrase <passphrase> <keygrip>

GPG-Agent-Prozess scheint ganz gut zu laufen, aber ich erhalte die folgenden Fehler aus der zweiten Zeile:

gpg-preset-passphrase: can't connect to `/home/<user>/.gnupg/S.gpg-agent': Connection refused
gpg-preset-passphrase: caching passphrase failed: Input/output error

Ich habe sicher, dass die Steckdose mit dem richtigen Berechtigungen vorhanden in dem Verzeichnis aus, und dieser Prozess wird als root ausgeführt. Es scheint, dass diese Fassung noch von Natur aus zu root gebunden ist, auch wenn ich kopiere und Berechtigungen ändern. Also meine Fragen sind

  1. Wie genau funktioniert diese Buchse initialisiert werden?
  2. Gibt es eine Möglichkeit, um manuell als einen anderen Benutzer zu tun?
Veröffentlicht am 03/12/2019 um 00:00
quelle vom benutzer
In anderen Sprachen...                            


1 antworten

stimmen
0

Es stellt sich heraus das Problem der nicht verwandt war gpg-agentund gpg-preset-passprhase.

Hinweis: Dies ist nicht eine dauerhafte Lösung , aber es hat mir zu erlauben , über die Frage zu bekommen ich gegenüberstand .

Nach der Änderung der /etc/selinux/configerfahrenen und Deaktivieren SE Linux, ich nicht mehr die Berechtigungen oben erteilen. SE Linux ist ein Sicherheits - Linux - Kernel - Modul von Red Hat entwickelt (ich bin derzeit läuft dies auf RHEL7). Es scheint , der nächste Schritt wird wahrscheinlich sicher zu machen sein , diese Binärdateien und Pakete sind erlaubt den Zugriff von meinem Benutzer verwenden audit2allow. Bit weitere Informationen zu diesem hier: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-fixing_problems-allowing_access_audit2allow

Beantwortet am 05/12/2019 um 17:56
quelle vom benutzer

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more