Como eu permito que usuários não-root controlem um serviço systemd com instâncias?

Question

Eu preciso permitir que os usuários no grupo dba controlem os serviços database@ . A resposta para questão relacionada é apenas listar todos os systemctl "verbos" que eu quero permitir no arquivo sudoers , no entanto, isso não se aplica ao meu caso porque eu não sei de antemão quais bancos de dados podem existir em o sistema. Por exemplo, se eu listar

%dba = /usr/bin/systemctl start database@awsesomeapp
%dba = /usr/bin/systemctl start database@anotherawsesomeapp
%dba = /usr/bin/systemctl start database@yetanotherawsesomeapp
%dba = /usr/bin/systemctl start database@wowyetanotherawsesomeapp
# ... other "verbs" omitted for brevity

que não abrange instâncias que possam existir no futuro e um dba não será capaz de

$ sudo systemctl start database@omgwowyetanotherawsesomeapp

De qualquer forma, estou pensando mais em termos de empacotamento do que em lidar com um sistema específico.

Observe que, como mostrado nesta resposta incrível a outra questão relacionada , usar o sudo globs para isso é inseguro:

%dba ALL = /usr/bin/systemctl start database@[a-z]* # UNSAFE!

permite

$ sudo systemctl start database@awsesomeapp unrelatedservice

Eu suspeito que usar sudo não vai resolver meu problema (embora eu tenha certeza que estou errado). Existe alguma outra maneira de permitir que usuários não-root controlem systemd serviços?

Por que vale a pena, eu preciso fazer isso em um sistema CentOS 7 e RHEL7 no futuro. Eu também estaria interessado em soluções que funcionem no Arch Linux.

    

Answer 1

O arquivo Sudoers não funciona assim, ou assim parece. O arquivo Sudoers tem como objetivo fornecer um acesso de comando específico, não especificar os argumentos que podem ir com esse comando.

Crie um script que seja executado como root e execute isso:

/usr/bin/systemctl start database@

Faça o script pegar um argumento como anotherawesomeapp para que ele execute isto:

O script é executado: / usr / bin / systemctl start database @ anotherawsesomeapp

Conceda aos seus usuários permissão para executar o arquivo script.sh com / etc / sudoers.

scriptuser ALL=(ALL) NOPASSWD: /path/to/script.sh

O usuário pode executá-lo assim:

sh script.sh anotherawsesomeapp

Exemplo:

AppName=$1

/usr/bin/systemctl start database@$AppName;
if [ $? != "0" ] 
then; 
    echo "$AppName could not be started. Are you using the right application name?";
fi

    

Answer 2

Uma solução proposta baseada em SUID

Você poderia criar o dito script que chama systemctl com o sudo. Faça o script de propriedade de root. Conceda a permissão SUID para fazer root, ler e executar permissões para o grupo de administradores de banco de dados (dba).
Apenas tome cuidado para não fornecer permissão de gravação para o grupo ou para os outros, pois dessa forma eles podem alterar o script e fazê-lo executar qualquer coisa precedida com o sudo! Verifique também se o script é à prova de bala.

$ cat >> start_database.sh
sudo /usr/bin/systemctl start database@$1
(Ctrl+D)

Este script pode ser melhorado verificando se o argumento é de fato fornecido e imprimir uma mensagem Usage: if if ..., também porque é um script com SUID que seria apropriado verificar; para evitar a injeção de outros comandos após o argumento. Ou, melhor ainda, permita inserir apenas uma das strings relacionadas ao aplicativo que você mencionou!
Em seguida, você deve garantir que as permissões para o script sejam estritamente as seguintes:

$ sudo chown root:dba start_database.sh
$ sudo chmod u-x,g-w,o-rwx start_database.sh
$ sudo chmod u+s,g+rx start_database.sh

Em seguida, para verificar as permissões corretas:

$ls -la
.
.
.
-rwSr-x--- 1 root dba       35 Aug  2 19:11 start_database.sh
.
.
.

Então, para recapitular:

 1. o owner of the script is root
 2. o arquivo can be read and executed by the dba group members
 3. no-one else will be able to even read it.
 4. SUID permitirá ao usuário que executa o script tornar-se root contanto que o script seja executado.
 5. Então o sudo não irá parar por uma senha.

Em qualquer caso, em um sistema com vários usuários, seja muito cuidadoso com SUID , pois isso pode deixar espaço para o abuso de permissão.