Come posso consentire agli utenti non root di controllare un servizio systemd con istanze?

Devo consentire agli utenti del dbagruppo di controllare i database@servizi. La risposta a questa domanda correlata è semplicemente elencare tutti i systemctl"verbi" che voglio consentire nel sudoersfile, tuttavia, che non si applicano al mio caso perché non so in anticipo quali database potrebbero esistere nel sistema. Ad esempio, se elenco

%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

che non copre casi che potrebbero esistere in futuro e un dba non sarà in grado di farlo

$ sudo systemctl start database@omgwowyetanotherawsesomeapp

Ad ogni modo, sto pensando più in termini di packaging che di fidelizzazione con un sistema specifico.

Nota che, come mostrato in questa straordinaria risposta a un'altra domanda correlata , l'uso di sudo globs per questo è in definitiva insicuro:

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

permette

$ sudo systemctl start database@awsesomeapp unrelatedservice

Sospetto che l'uso sudonon risolverà il mio problema (anche se spero di sbagliarmi). Esiste un altro modo per consentire agli utenti non root di controllare i systemdservizi?

Per quello che vale, devo farlo in un sistema CentOS 7 e in RHEL7 in futuro. Sarei anche interessato a soluzioni che funzionano su Arch Linux.

Il file dei sudatori non funzionerà in questo modo, o almeno così mi sembra. Il file Sudoers ha lo scopo di dare un accesso specifico al comando, non di specificare gli argomenti che possono andare con quel comando.

Crea uno script che viene eseguito come root ed esegue questo:

/usr/bin/systemctl start database@

Fai in modo che lo script prenda un argomento come anotherawesomeapp in modo che esegua questo:

Lo script viene eseguito: / usr / bin / systemctl start database @ anotherawsesomeapp

Concedi ai tuoi utenti il ​​permesso di eseguire il file script.sh con / etc / sudoers.

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

L'utente può eseguirlo in questo modo:

sh script.sh anotherawsesomeapp

Esempio:

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

Una soluzione proposta basata suSUID

You potrebbe creare il suddetto script che chiama systemctl con sudo. Rendi lo script di proprietà di root. Fornire le SUIDautorizzazioni per eseguire il root, leggere ed eseguire le autorizzazioni per il gruppo di amministratori del database (dba).
Fai solo attenzione a non fornire il permesso di scrittura al gruppo o ad altri perché in questo modo potrebbero cambiare lo script e fargli eseguire qualsiasi cosa preceduta con sudo! Assicurati anche che lo script sia a prova di proiettile in termini di input.

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

Questo script può essere migliorato controllando se l'argomento è effettivamente fornito e stampa un Uso: messaggio in caso contrario ..., anche dal momento che è uno script con SUIDesso sarebbe opportuno verificare; per evitare l'iniezione di altri comandi seguendo l'argomento. O ancora meglio assicurati di consentire come input solo una delle stringhe relative all'app che hai citato!
Quindi è necessario assicurarsi che le autorizzazioni per lo script siano rigorosamente le seguenti:

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

Quindi per verificare le autorizzazioni corrette:

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

Quindi, per ricapitolare:

1. il owner of the script is root
2. il file can be read and executed by the dba group members
3. no-one else will be able to even readesso.
4. SUIDconsentirà all'utente che esegue lo script di diventare root fintanto che lo script viene eseguito.
5. Quindi sudo non si fermerà per una password.

In ogni caso, in un sistema con più utenti, essere molto attenti con SUIDperché può lasciare spazio per abuso permesso.