GPG Kan geen verbinding maken S.gpg-agent: verbinding geweigerd

stemmen
0

Ik probeer op te zetten gpg vooraf ingestelde passphrase caching met behulp van de gpg-agent, dus ik mijn dossier encryptie proces kan automatiseren. Om de GPG-middel om te draaien en op de juiste cache van het wachtwoord, lijkt moet er een zijn S.gpg agent- socket zich in de ~ / .gnupg / directory die wordt gegenereerd in de root directory als ik het opzetten van gpg en gpg agent.

Wat ik heb gedaan (en die leek te werken in het verleden) is dat ik zou beginnen alles als root en kopiëren over de inhoud van de /.gnupg directory aan mijn minder bevoorrechte gebruiker en machtigingen verlenen aan die socket en directory voor de gebruiker. De commando Ik rende naar het opstarten van de gpg-agent-daemon en cache passphrase:

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

gpg-agent-proces lijkt prima te lopen, maar ik krijg de onderstaande fout van de tweede regel:

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

Ik heb zorgde ervoor dat het stopcontact bestaat in de directory met de juiste machtigingen en dit proces draait als root. Het lijkt erop dat deze bus is nog steeds inherent verbonden met wortel, zelfs als ik kopieer en Machtigingen wijzigen. Dus mijn vragen zijn

  1. Hoe precies doet deze bus geïnitialiseerd?
  2. Is er een manier om dit handmatig te doen als een andere gebruiker?
De vraag is gesteld op 03/12/2019 om 00:00
bron van user
In andere talen...                            


1 antwoorden

stemmen
0

Het blijkt dat de kwestie was niet gerelateerd aan de gpg-agenten gpg-preset-passprhase.

Opmerking: Dit is niet een permanente oplossing, maar het deed mij toe om voorbij de kwestie die ik werd geconfronteerd te krijgen.

Na het wijzigen van de /etc/selinux/configen het uitschakelen van SE Linux, ik niet meer meegemaakt de machtigingen af te geven boven. SE Linux is een Linux kernel beveiligingsmodule ontwikkeld door Red Hat (ik dit momenteel op RHEL7). Het lijkt erop dat de volgende stap zal waarschijnlijk zijn om te zorgen dat deze binaries en pakketten worden toegestaan toegang vanaf mijn gebruiker met behulp van audit2allow. Beetje meer informatie over dit 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

antwoordde op 05/12/2019 om 17:56
bron van user

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