GPG não é possível conectar ao S.gpg-agent: Conexão recusada

votos
0

Eu estou tentando configurar gpg predefinido senha cache utilizando o agente gpg para que eu possa automatizar o meu processo de criptografia de arquivos. Para que o gpg-agent para executar e devidamente armazenar em cache a senha, parece que não precisa ser um S.gpg-agente tomada localizado dentro do ~ / .gnupg / diretório que será gerado no diretório raiz quando eu configurar gpg e gpg-agente.

O que eu fiz (e que parecia trabalho no passado) é que eu iria começar-se tudo como root e copiar o conteúdo do diretório /.gnupg aos meus menos privilegiadas permissões de usuário e conferir a essa tomada e diretório para o usuário. Os comandos Corri para iniciar o daemon gpg-agent e senha de cache:

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

processo gpg-agent parece estar a correr bem, mas fico com a abaixo de erro a partir da segunda linha:

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

Tenho a certeza da tomada existe no diretório com permissões adequadas e este processo é executado como raiz. Parece que esta tomada ainda está intrinsecamente ligada à raiz mesmo se eu copiar e modificar permissões. Então, minhas perguntas são

  1. Como exatamente esta tomada obter inicializado?
  2. Existe uma maneira de fazê-lo manualmente como outro usuário?
Publicado 03/12/2019 em 00:00
fonte usuário
Em outras línguas...                            


1 respostas

votos
0

Acontece que o problema não estava relacionado com o gpg-agente gpg-preset-passprhase.

Nota: Esta é não uma solução permanente, mas me permitiu passar o problema que estava enfrentando.

Depois de modificar o /etc/selinux/confige incapacitante SE Linux, eu já não experimentou as permissões emitir acima. SE Linux é um módulo de segurança do kernel Linux desenvolvida pela Red Hat (Atualmente, estou executando isso em RHEL7). Parece que o próximo passo será provavelmente para se certificar esses binários e pacotes é permitido o acesso do meu usuário usando audit2allow. Bit mais informações sobre este aqui: 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

Respondeu 05/12/2019 em 17:56
fonte usuário

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