snmptt executando como não raiz, escrevendo no arquivo como raiz

Question

Estou executando snmptt como um manipulador de traps SNMP para snmptrapd , com o objetivo de gravar em um arquivo trap que possa ser lido e processado pelo Zabbix.

Eu configurei o snmptt para ser executado como o usuário zabbix alterando o script init .

# grep daemon /etc/init.d/snmptt
# description: SNMP Trap Translator daemon
# Short-Description: SNMP Trap Translator daemon
OPTIONS="--daemon"
        daemon --user=zabbix /usr/sbin/snmptt $OPTIONS

snmpttt está sendo executado como esperado como o usuário zabbix , o mesmo usuário que está executando o servidor Zabbix.

# ps -ef | grep snmp
root      3796     1  0 Jun19 ?        00:13:04 /usr/sbin/snmpd -LS0-6d -Lf /dev/null -p /var/run/snmpd.pid
zabbix    4444     1  0 15:00 ?        00:00:00 /usr/bin/perl /usr/sbin/snmptt --daemon
zabbix    4445  4444  0 15:00 ?        00:00:00 /usr/bin/perl /usr/sbin/snmptt --daemon
root      9300 29899  0 15:25 pts/2    00:00:00 grep snmp
zabbix   16576 16511  0 Aug16 ?        00:00:11 /path/to/sbin/zabbix_server: snmp trapper [processed data in 0.000007 sec, idle 1 sec]
root     16600     1  0 Aug16 ?        00:00:07 /usr/sbin/snmptrapd -A -Lf /var/log/snmptrapd.log -D -p /var/run/snmptrapd.pid

O arquivo de log para enviar traps capturados é /var/tmp/zabbixtest/zabbix_traps.tmp

# egrep "^(log_file|pid)" /etc/snmp/snmptt.ini
pid_file = /var/run/snmptt/snmptt.pid
log_file=/var/tmp/zabbixtest/zabbix_traps.tmp

No entanto, o arquivo de log de trap está sendo gravado e pertence ao usuário root , não como o usuário zabbix conforme o esperado. Além disso, as permissões no arquivo são 0640 , o que significa que o usuário do zabbix que está executando o servidor não consegue ler o arquivo.

# service snmptt stop
Stopping snmptt:                                           [  OK  ]
# rm /var/tmp/zabbixtest/zabbix_traps.tmp
rm: remove regular file '/var/tmp/zabbixtest/zabbix_traps.tmp'? y
# ls -lia /var/tmp/zabbixtest/zabbix_traps.tmp
ls: cannot access /var/tmp/zabbixtest/zabbix_traps.tmp: No such file or directory
# ls -lia /var/tmp/zabbixtest/
total 24
263224 drwxrwxr-x 2 root zabbix 4096 Aug 17 15:32 .
262145 drwxrwxrwt 7 root root   4096 Aug 17 14:53 ..
# service snmptt start
Starting snmptt: PID file: /var/run/snmptt/snmptt.pid
                                                           [  OK  ]
# ps -ef | grep snmptt
zabbix    9944     1  0 15:32 ?        00:00:00 /usr/bin/perl /usr/sbin/snmptt --daemon
zabbix    9945  9944  0 15:32 ?        00:00:00 /usr/bin/perl /usr/sbin/snmptt --daemon
root      9981 29899  0 15:32 pts/2    00:00:00 grep snmptt
# ps -ef | grep snmp
root      3796     1  0 Jun19 ?        00:13:04 /usr/sbin/snmpd -LS0-6d -Lf /dev/null -p /var/run/snmpd.pid
zabbix    9944     1  0 15:32 ?        00:00:00 /usr/bin/perl /usr/sbin/snmptt --daemon
zabbix    9945  9944  0 15:32 ?        00:00:00 /usr/bin/perl /usr/sbin/snmptt --daemon
root      9986 29899  0 15:32 pts/2    00:00:00 grep snmp
zabbix   16576 16511  0 Aug16 ?        00:00:11 /path/to/sbin/zabbix_server: snmp trapper [processed data in 0.000079 sec, idle 1 sec]
root     16600     1  0 Aug16 ?        00:00:07 /usr/sbin/snmptrapd -A -Lf /var/log/snmptrapd.log -D -p /var/run/snmptrapd.pid
# ls -lia /var/tmp/zabbixtest/zabbix_traps.tmp
262265 -rw-r----- 1 root root 122 Aug 17 15:32 /var/tmp/zabbixtest/zabbix_traps.tmp

Anote as permissões de arquivo e a propriedade de /var/tmp/zabbixtest/zabbix_traps.tmp .

Consequentemente, o usuário zabbix não consegue ler o arquivo e, portanto, é incapaz de processá-lo.

Posso corrigir modificando manualmente o modo do arquivo de interceptação /var/tmp/zabbixtest/zabbix_traps.tmp para 0644 , por exemplo, mas espero que haja uma maneira melhor, por exemplo por meio de um arquivo de configuração, pois a localização do arquivo provavelmente será alterada. (Existem alguns sites de blogs recomendando mudar o modo para 0777, obviamente essa não é a solução correta).

Acho que é devido à configuração de snmptrapd , sendo executado como root, mas não tenho certeza da melhor maneira de corrigir isso.

Minhas perguntas:

Por que o arquivo de log de trap foi gravado como root user com 0640 permissions, em vez de zabbix user executando snmptt ?

Como posso / devo configurar snmptt e / ou snmptrapd para que o arquivo trap seja de propriedade e legível pelo usuário zabbix em vez do usuário root.

Outras informações relevantes:

arquivo de configuração snmptrapd:

# grep -v '^#' /etc/snmp/snmptrapd.conf
disableAuthorization yes

traphandle default /usr/sbin/snmptthandler

Rodando o RHEL 6.6

    

Answer 1

Encontrou uma solução pelo menos após o comentário de Richlv sobre o arquivo que está sendo criado no modo independente.

Fiz algumas alterações e consegui pelo menos uma solução de trabalho.

Acho que não reiniciei snmptrapd depois de alterar snmptrapd.conf para ler traphandle default /usr/sbin/snmptthandler em vez de traphandle default /usr/sbin/snmptt .

Por que escrito como root

Uma nova instância de snmptt estava sendo chamada por snmptrapd , que estava sendo executada como raiz e deve ser vinculada à porta snmp 162. Portanto, os arquivos gravados por snmptt também eram de propriedade de root.

As permissões, no entanto, continuam sendo um mistério para mim. Não posso dizer de onde as permissões 0640 estão vindo.

Principais alterações que se acredita terem corrigido o problema

1. Reinicie o snmptrapd ( service snmptrapd restart ), que causou a releitura de snmptrapd.conf , para garantir que snmptthandler seja usado para processar traps em vez de snmptt , que foi gravado anteriormente no arquivo de configuração.

Isso não corrige o problema inteiro, já que agora snmptthandler escreve traps no diretório de spool /var/spool/snmptt , que é subseqüentemente lido pelo processo de snmptt daemon:

# grep spool_directory /etc/snmp/snmptt.ini
spool_directory = /var/spool/snmptt/

# grep -A5 SPOOL /usr/sbin/snmptthandler
...
while (defined(my $line = <>))
{
        print SPOOL $line;

        if ($DEBUGGING >= 1)
        {
                # Print out item passed from snmptrapd
                print $line."\n";
        }

Os arquivos de spool pertencerão a root , com as mesmas permissões 0640 que foram emitidas com o arquivo de log de snmptt no modo autônomo. Isso significa que o processo daemon snmptt ainda não poderá lê-los e processá-los depois que snmptthandler estiver concluído. (No arquivo de log /var/log/snmptt/snmptt.debug , haverá um erro permissions denied ao tentar ler o arquivo de spool.)

Então, o próximo passo:

Defina a propriedade do diretório de spool para ser o usuário snmptt daemon e use o set-gid no diretório de spool, fazendo com que os novos arquivos gravados sejam de propriedade de e sejam legíveis pelo usuário que está executando snmptt .

chown zabbix:zabbix /var/spool/smptt
chmod g+s /var/spool/smptt
#ls -lia /var/spool/snmptt/
total 8
209 drwxrwsr-x  2 zabbix zabbix 4096 Aug 18 11:40 .
#ps -ef | grep snmptt
zabbix    8787     1  0 12:44 ?        00:00:00 /usr/bin/perl /usr/sbin/snmptt --daemon

Depois disso, o daemon snmptt poderá ler os arquivos em spool e gravará os arquivos no diretório de log esperado /var/tmp/zabbixtest/zabbix_traps.tmp como o usuário zabbix , não como raiz.

### After a trap is received 
# ls -lia /var/tmp/zabbixtest/snmptt.log
524605 -rw-rw-r--  1 zabbix zabbix   646 Aug 18 13:16 snmptt.log

O umask para o arquivo de log é do script snmptt :

$ grep -i umask /usr/sbin/snmptt
#umask 0;
umask 002;
  #umask 0;
  umask 002;

Outras mudanças, boa prática, mas não acredito que tenham impactado diretamente o resultado

1. Alterou snmptt.ini para ler mode=daemon em vez de mode=standalone . (Não está claro o efeito que isso teve, se houver)
2. Altere /etc/snmp/snmptt.ini para ler daemon_uid= (em branco) em vez de daemon_uid=zabbix (isso é recomendado em snmp docs e evita os processos de snmptt duplos pelo mesmo usuário.

Então, há uma maneira de corrigir isso. Não tenho certeza se é o melhor caminho. A melhor maneira pode incluir a alteração de snmptthandler para usar o usuário / umask definido no arquivo de configuração.

Isso não responde à pergunta completa (0640 permissões ainda não estão claras) Comentários ou assistência são bem-vindos para isso.