Galera + systemd: wsrep_notify_cmd falha com sudo (não é possível alterar para sudoers gid: operação não permitida)

1

Temos um cluster Galera operacional no CentOS 7 com sysv e estamos procurando migrar para o systemd. Estamos invocando um wsrep_notify_cmd para notificar nossa aplicação de mudanças nos estados de nós, e precisamos combinar isso com sudo porque nosso aplicativo está em um diretório com outro usuário / grupo ao qual mysql não tem acesso.

Com o sysv init, isso funciona bem, pois o comando / script é iniciado como root. Com o systemd, o comando / script é iniciado sob o mysql user - portanto, precisamos configurar os sudoers para que ele funcione. Ou então pensamos.

Depois de mudar para o systemd, continuei vendo sudo: unable to change to sudoers gid: Operation not permitted em nossos logs, então fiz alguns testes / depurações com a idéia de primeiro iniciar um script para o qual mysql tenha direitos, e esse script, por sua vez, passará os argumentos wsrep_notify_cmd para outro script ( /data/app/notify.sh ) usando sudo .

Observação: o SELinux está desativado.

configuração do servidor MySQL

Configuração do servidor (teste) do MySQL: wsrep_notify_cmd='/mysql/notify.sh'

Configuração de Sudoers

/etc/sudoers.d/mysql está configurado da seguinte forma:

Defaults:mysql !requiretty
Defaults:mysql umask=0007

Cmnd_Alias NOTIFY = /bin/bash /data/app/notify.sh*
mysql ALL=(app_user) NOPASSWD: NOTIFY

Teste manual

Agora, sudo su - mysql e, em seguida, a execução manual de /mysql/notify.sh funciona bem:

[mysql@testhost /mysql]$ /bin/sudo -u app_user /bin/bash /data/app/notify.sh --status Synced
[mysql@testhost /mysql]$ 

O script /data/app/notify.sh , sendo executado como app_user grava todos os parâmetros passados em um arquivo - e executa com êxito a execução do comando acima manualmente:

[root@testhost /data/app]# cat output.log 
--status Synced

Mesma coisa, mas de dentro do systemd mysql service init

No entanto, ao fazer service mysql start , o script /mysql/notify.sh não executará seu trabalho como deveria e, em vez disso, negará acesso a qualquer sudo comando: sudo: unable to change to sudoers gid: Operation not permitted .

Estou executando este script usando #!/bin/bash -xv e redirecionando o stderr para um arquivo de log:

[mysql@testhost /mysql]$ cat debug.log 

file=/mysql/args.log
+ file=/mysql/args.log

echo $USER
+ echo mysql

ARGS="$@"
+ ARGS='--status Synced'

/bin/sudo -K
+ /bin/sudo -K
sudo: unable to change to sudoers gid: Operation not permitted
/bin/sudo -u app_user /bin/bash /data/app/notify.sh $ARGS
+ /bin/sudo -u app_user /bin/bash /data/app/notify.sh --status Synced
sudo: unable to change to sudoers gid: Operation not permitted

Como você pode ver, o mesmo comando que eu consegui executar manualmente a partir do shell de usuário mysql está NOT funcionando ao ser invocado a partir do mesmo script ao ser executado como parte do systemd service mysql start .

O que poderia causar isso?

    
por Erik 20.02.2016 / 17:10

1 resposta

0

Se você quiser derrotar a segurança do systemd aqui, você pode modificar os recursos da Unidade, por exemplo:

# systemctl show mysql | grep Cap

-- CapabilityBoundingSet=16384

# vim /usr/lib/systemd/system/mariadb.service

-- CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_NET_RAW CAP_NET_ADMIN CAP_SETUID CAP_SYS_ADMIN

systemctl daemon-reload

systemctl restart mysqld

systemctl show mysql | grep Cap

-- CapabilityBoundingSet=2126016

Note que menos recursos podem ser necessários, isso foi apenas um teste rápido

Não modifique o arquivo real, use, por exemplo, /etc/systemd/system/mariadb.service.d/MY_SPECIAL.conf

    
por 06.03.2018 / 23:05

Tags