Instalei o PostgresQL em uma caixa do Centos 7 habilitada para o SELinux e alterei seu diretório de dados padrão para / srv / postgres, um grupo de volume LVM / volume lógico criptografado por LUKS separado, por razões de mobilidade, no caso de eu ter que mover o servidor, e confidencialidade, se a mídia de dados for roubada ou exposta enquanto estiver em movimento. Eu acho que a funcionalidade LUKS / LVM envolvida não deve afetar o meu problema, mas mencioná-lo por razões de integridade.
Agora, quando eu inicio o serviço postgresql:
root@fafner:~ # systemctl start postgresql
... eu recebo isso em /var/log/audit/audit.log:
root@fafner:~ # tail -f /var/log/audit/audit.log | grep "postgresql"
[..]
type=AVC msg=audit(1476614020.689:522): avc: denied { open } for pid=2900 comm="pg_ctl" path="/srv/postgres/data/postgresql.conf" dev="dm-4" ino=136 scontext=system_u:system_r:postgresql_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=file type=SYSCALL msg=audit(1476614020.689:522): arch=c000003e syscall=2 success=no exit=-13 a0=7ffc681cc430 a1=0 a2=1b6 a3=24 items=1 ppid=1 pid=2900 auid=4294967295 uid=989 gid=986 euid=989 suid=989 fsuid=989 egid=986 sgid=986 fsgid=986 tty=(none) ses=4294967295 comm="pg_ctl" exe="/usr/bin/pg_ctl" subj=system_u:system_r:postgresql_t:s0 key=(null)
type=PATH msg=audit(1476614020.689:522): item=0 name="/srv/postgres/data/postgresql.conf" inode=136 dev=fd:04 mode=0100600 ouid=989 ogid=986 rdev=00:00 obj=unconfined_u:object_r:var_t:s0 objtype=NORMAL
type=AVC msg=audit(1476614020.725:523): avc: denied { open } for pid=2904 comm="postgres" path="/srv/postgres/data/postgresql.conf" dev="dm-4" ino=136 scontext=system_u:system_r:postgresql_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=file type=SYSCALL msg=audit(1476614020.725:523): arch=c000003e syscall=2 success=no exit=-13 a0=befc30 a1=0 a2=1b6 a3=24 items=1 ppid=2900 pid=2904 auid=4294967295 uid=989 gid=986 euid=989 suid=989 fsuid=989 egid=986 sgid=986 fsgid=986 tty=(none) ses=4294967295 comm="postgres" exe="/usr/bin/postgres" subj=system_u:system_r:postgresql_t:s0 key=(null)
type=PATH msg=audit(1476614020.725:523): item=0 name="/srv/postgres/data/postgresql.conf" inode=136 dev=fd:04 mode=0100600 ouid=989 ogid=986 rdev=00:00 obj=unconfined_u:object_r:var_t:s0 objtype=NORMAL
type=SERVICE_START msg=audit(1476614021.712:524): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=postgresql comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Eu tentei usar o audit2allow para corrigir o problema:
root@fafner:~ # grep "postgresql" /var/log/audit/audit.log | audit2allow -M postgresql_tskjoedt
root@fafner:~ # semodule -i postgresql_tskjoedt.pp
... processando alguma saída em /var/log/audit/audit.log que eu removi do post desde que se mostrou irrelevante. Não resolveu o problema, no entanto, o erro persiste exatamente da mesma forma.
Eu também tentei:
root@fafner:~ # restorecon -Rv /usr/bin/pg_ctl
root@fafner:~ # restorecon -Rv /usr/bin/postgres
root@fafner:~ # restorecon -Rv /srv/postgres/data
... e até mesmo tocando um arquivo '.autorelabel' nos sistemas de arquivos root e postgres, e reinicializando, para re-marcar tudo o que estiver envolvido. Mas ainda recebo o mesmo erro "negado aberto para pg_ctl no postgresql.conf" em audit.log.
Eu fiz essas coisas algumas vezes, presumindo que as alterações não são cumulativas.
De esta resposta e alguns dos links aos quais ela se refere eu concluo que, de alguma forma, esses contextos / rótulos do SELinux não estão alinhados corretamente:
root@fafner:~ # ls -Z /usr/bin/pg_ctl
-rwxr-xr-x. root root system_u:object_r:postgresql_exec_t:s0 /usr/bin/pg_ctl
root@fafner:~ # ls -Z /usr/bin/postgres
-rwxr-xr-x. root root system_u:object_r:postgresql_exec_t:s0 /usr/bin/postgres
root@fafner:~ # ls -Z /srv/postgres/data/postgresql.conf
-rw-------. postgres postgres unconfined_u:object_r:var_t:s0 /srv/postgres/data/postgresql.conf
Eu poderia simplesmente embaralhar os rótulos até que algo possa começar a funcionar, mas eu não quero arbitrariamente definir ou arruinar os rótulos do SELinux apenas para fazer as coisas funcionarem; então eu poderia simplesmente desligar o SELinux.
Além disso, não entendo por que o 'audit2allow' não corrige o problema específico; Esse comando não deveria fazer exatamente isso, em essência, ampliar o contexto do SELinux apenas o suficiente para que a operação específica seja permitida?
Toda esta questão decorre, obviamente, da minha falta de compreensão do SELinux, e grande parte da saída do audit.log é relativamente obscura para mim. Alguém pode identificar a pista que eu deveria estar percebendo?
Atenciosamente,
LANerd