Aqui está o cenário, estamos usando o GnuPG para criptografar dados entre dois servidores da web. 1 está no RHEL. O GnuPG será acessado através de scripts cgi para criptografar e descriptografar. Então eu preciso de um chaveiro que o usuário do apache tenha acesso. Isso provou ser difícil para mim no Red Hat, eu consegui instalar isso facilmente no Ubuntu. Aqui está o que eu tentei, talvez alguém tenha uma maneira melhor / mais fácil de realizar isso.
Eu me tornei o usuário do apache
su -s /bin/bash apache
ao correr
gpg --gen-key
não foi possível criar o diretório .gnupg em / var / www, então criei isso e configurei o proprietário para apache.apache. agora, ao gerar chaves, recebo
can't connect to '/var/www/.gnupg/S.gpg-agent': No such file or directory
gpg-agent[26949]: command get_passphrase failed: Operation cancelled
gpg: cancelled by user
gpg: Key generation canceled.
então eu criei esse arquivo, depois de ler a página man um pouco (e alguns googling)
mknod -m 700 S.gpg-agent p
agora eu recebo
can't connect to '/var/www/.gnupg/S.gpg-agent': Connection refused
gpg-agent[26949]: command get_passphrase failed: Operation cancelled
gpg: cancelled by user
gpg: Key generation canceled.
Eu não consegui chegar a lugar algum depois disso, já que estou entrando em áreas que eu não conheço muito. Eu estou supondo que isso tenha a ver com o fato de que o apache não é realmente um usuário no desde ter um perfil bash, etc. Então, para onde eu vou daqui?
Já tentou criar um novo usuário e invocar o comando com o sudo? Se temer isso pode ser algum problema de permissão e a maneira mais fácil seria remover o nó do agente de / var / www para algum lugar que conhecemos que seja acessível ao usuário gpg, talvez o diretório / tmp. Você pode especificar manualmente a localização do nó do agente alterando a variável env GPG_AGENT_INFO.
Esse é provavelmente um problema de permissão de arquivo do dispositivo. pinentry não usa os descritores de arquivos herdados, mas tenta acessar o TTY transmitido diretamente, o que não funciona.
Você pode executar tty no shell e depois ls -l /dev/pts/1 com o resultado e provavelmente perceberá que apache não tem acesso a ele.
Você também pode executar
strace -o gpg.strace -f -e trace=open gpg --gen-key
e provavelmente encontrará algo como
open("/dev/pts/1", O_RDONLY) = -1 EACCES (Permission denied)
A solução perigosa é (temporariamente) conceder acesso apache a um console root ... ( chown apache /dev/pts/1 ). A melhor solução é fazer um login real como apache .
Isso afeta apenas a geração de chaves. Você também pode criar um par de chaves como outro usuário, exportá-lo e importá-lo na conta apache .
Suspeito que seja uma regressão em relação a esse bug link
Da errata:
This update fixes the following bug:
- Prior to this update, there was a problem when entering a password using the pinentry-curses utility; an error message was displayed instead of the password entry dialog if pinentry-curses was run under a user different from the user who owned the current tty. This bug has been fixed in this update so that no error message is now displayed and pinentry-curses asks for a password as expected. (BZ#677665)
O problema parece ser, quando você su ou sudo, o tty ainda é propriedade do dono original do tty, que explode pinentry.
Eu notarei que não pudemos criar chaves gpg como qualquer outro usuário que não root em um sistema Cent 6 ontem. Para gerar as chaves, tivemos que fazer login como root, criar as chaves, copiar o diretório .gpg no diretório pessoal do usuário e alterar a propriedade.
Tags encryption gpg gpg-agent rhel