GPG Non è possibile collegarsi a S.gpg-agent: Connection Refused

voti
0

Sto tentando di installare gpg preimpostato passphrase caching utilizzando l'agente gpg in modo da poter automatizzare il mio processo di crittografia dei file. Affinché il gpg-agent per eseguire e memorizzare nella cache la passphrase corretta, sembra che ci deve essere un S.gpg-agent presa situata all'interno della / .gnupg / directory ~ che viene generato nella directory principale quando ho creato gpg e gpg-agent.

Quello che ho fatto (e che sembrava funzionare in passato) è vorrei iniziare a tutto come root e copiare il contenuto della directory /.gnupg ai miei meno privilegiati i permessi degli utenti e rilasciare alla presa di corrente e directory per l'utente. I comandi che ho incontrato per avviare il daemon gpg-agent e la cache passphrase:

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

processo di gpg-agent sembra funzionare bene, ma ho l'sotto l'errore dalla seconda linea:

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

Ho fatto in modo che la presa esiste nella directory con autorizzazioni appropriate e questo processo viene eseguito come root. Sembra che questo socket è ancora intrinsecamente legata alla radice, anche se copio e autorizzazioni Modifica. Quindi le mie domande sono

  1. Come funziona esattamente questa presa ottenere inizializzato?
  2. C'è un modo per farlo manualmente da un altro utente?
È pubblicato 03/12/2019 alle 00:00
fonte dall'utente
In altre lingue...                            


1 risposte

voti
0

Si scopre che il problema era estraneo alla gpg-agente gpg-preset-passprhase.

Nota: Questo è non è una soluzione permanente, ma mi ha permesso di andare oltre il problema che stavo affrontando.

Dopo aver modificato il /etc/selinux/confige invalidante SE Linux, ho sperimentato più i permessi questione di cui sopra. SE Linux è un modulo di protezione del kernel di Linux sviluppata da Red Hat (Sono attualmente in esecuzione su questo RHEL7). Sembra che il prossimo passo sarà probabilmente per rendere l'accesso sicuro che questi binari e pacchetti sono permessi dal mio utente che utilizza audit2allow. Bit ulteriori informazioni su questo qui: 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

Risposto il 05/12/2019 a 17:56
fonte dall'utente

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