Erro de stunnel - não é possível abrir o arquivo de log

0

Usando o seguinte arquivo de configuração do stunnel:

chroot = /var/run/stunnel
setuid = nobody
setgid = nobody

debug = 7 
output = /var/log/stunnel/stunnel.log 
pid = /stunnel.pid

cert = /etc/stunnel/stunnel.pem 
key = /etc/stunnel/stunnel.pem 
client = yes

[https] 
accept = 127.0.0.1:10051
connect = 10.0.10.116:443

Digitando "stunnel sudo", recebo a seguinte saída. (O arquivo de configuração funciona se eu usar o comando em primeiro plano e enviar o log para o terminal)

[chuck@scorch ~]$ sudo stunnel
Clients allowed=500
stunnel 4.56 on x86_64-redhat-linux-gnu platform
Compiled/running with OpenSSL 1.0.1e-fips 11 Feb 2013
Threading:PTHREAD Sockets:POLL,IPv6 SSL:ENGINE,OCSP,FIPS Auth:LIBWRAP
Reading configuration from file /etc/stunnel/stunnel.conf
FIPS mode is enabled
Compression not enabled
PRNG seeded successfully
Initializing service [https]
Insecure file permissions on /etc/stunnel/stunnel.pem
Certificate: /etc/stunnel/stunnel.pem
Certificate loaded
Key file: /etc/stunnel/stunnel.pem
Private key loaded
SSL options set: 0x01000004
Configuration successful
Service [https] (FD=12) bound to 127.0.0.1:10051
Cannot open log file: /var/log/stunnel/stunnel.log
Closing service [https]
Service [https] closed (FD=12)
Sessions cached before flush: 0
Sessions cached after flush: 0
Service [https] closed
str_stats: 16 block(s), 1147 data byte(s), 928 control byte(s)

Suponho que isso seja algum tipo de problema de direitos, devido ao 'comando chroot', mas tentei definir os direitos no diretório de log stunnel como 'nobody: nobody', que não funcionou. Então, não estou entendendo adequadamente o que está acontecendo. Se eu deixar a linha 'chroot' e 'pid', funciona? Eu tenho certeza que isso é algo óbvio que eu simplesmente não vejo, alguma idéia?

Estou executando isso no Centos 7

    
por Charles Bunn 27.09.2017 / 23:13

2 respostas

1

Graças a thrig e Kusalananda , encontrei uma maneira de fazer isso funcionar colocando o arquivo de log no diretório /var/run/stunnel . Então, após uma reinicialização, eu recrio o diretório com sudo mkdir /var/run/stunnel e, em seguida, defino os direitos com sudo chown nobody:nobody /var/run/stunnel Embora isso desapareça depois de uma reinicialização pelo menos enquanto ele estiver em execução, posso ver o log em segundo plano durante o teste e após a inicialização. Eu ainda não entendi porque chroot não afeta os locais de chave e certificado da mesma forma que causou um problema com os arquivos de log?

    
por 29.09.2017 / 18:22
-1

Eu poderia resolver o problema usando um caminho relativo para o arquivo de log, como:

output = stunnel.log
chroot = / var / run / stunnel

    
por 20.09.2018 / 11:02