Jak zezwolić użytkownikom innym niż root na kontrolowanie usługi systemowej za pomocą instancji?

Muszę zezwolić użytkownikom w dbagrupie na kontrolowanie database@usług. Odpowiedzią na to pokrewne pytanie jest po prostu wypisanie wszystkich systemctl„czasowników”, które chcę dopuścić w sudoerspliku, jednak nie dotyczy to mojej sprawy, ponieważ nie wiem z góry, jakie bazy danych mogą istnieć w systemie. Na przykład, jeśli wymienię

%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

nie obejmuje to instancji, które mogą istnieć w przyszłości, a dba nie będzie w stanie tego zrobić

$ sudo systemctl start database@omgwowyetanotherawsesomeapp

W każdym razie myślę bardziej o pakowaniu niż o majstrowaniu przy konkretnym systemie.

Zauważ, że jak pokazano w tej niesamowitej odpowiedzi na inne powiązane pytanie , użycie globów sudo do tego celu jest ostatecznie niepewne:

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

pozwala

$ sudo systemctl start database@awsesomeapp unrelatedservice

Podejrzewam, że używanie sudonie rozwiąże mojego problemu (chociaż mam nadzieję, że się mylę). Czy istnieje inny sposób, aby umożliwić użytkownikom innym niż root kontrolowanie systemdusług?

Aby to było warte, muszę to zrobić w systemie CentOS 7 i systemach RHEL7 w przyszłości. Byłbym także zainteresowany rozwiązaniami, które działają na Arch Linux.

Plik Sudoers nie będzie tak działał, a przynajmniej tak mi się wydaje. Plik Sudoers ma na celu zapewnienie dostępu do określonego polecenia, a nie do określania argumentów, które mogą towarzyszyć temu poleceniu.

Utwórz skrypt, który działa jako root i wykonuje to:

/usr/bin/systemctl start database@

Niech skrypt przyjmuje argument, taki jak anotherawesomeapp, aby wykonał to:

Skrypt wykonuje: / usr / bin / systemctl start database @ anotherawsesomeapp

Zezwól użytkownikom na uruchomienie pliku script.sh z / etc / sudoers.

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

Użytkownik może uruchomić go w następujący sposób:

sh script.sh anotherawsesomeapp

Przykład:

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

Proponowane rozwiązanie oparte naSUID

Możesz utworzyć wspomniany skrypt, który wywołuje systemctl z sudo. Utwórz skrypt należący do roota. Zezwól SUIDna rootowanie, odczytywanie i wykonywanie uprawnień grupie administratorów baz danych (dba).
Uważaj tylko, aby nie udzielić pozwolenia na zapis grupie ani innym osobom, ponieważ w ten sposób mogą zmienić skrypt i spowodować, że wykona wszystko poprzedzone sudo! Upewnij się również, że skrypt jest kuloodporny pod względem wejściowym.

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

Skrypt ten można ulepszyć, sprawdzając, czy argument rzeczywiście został dostarczony, i wypisuje komunikat Użycie: komunikat, jeśli nie ..., ponieważ jest to skrypt, w SUIDprzypadku którego należy sprawdzić; aby uniknąć wstrzyknięcia innych poleceń po argumencie. Lub jeszcze lepiej upewnij się, że zezwalasz na wprowadzanie tylko jednego z ciągów związanych z aplikacją, o których wspomniałeś!
Następnie upewnij się, że uprawnienia do skryptu są następujące:

$ 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

Następnie, aby zweryfikować poprawne uprawnienia:

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

Tak więc, aby podsumować:

1. owner of the script is root
2. Plik can be read and executed by the dba group members
3. no-one else will be able to even readto.
4. SUIDpozwoli użytkownikowi, który wykonuje skrypt, stać się rootem, dopóki skrypt jest wykonywany.
5. Więc sudo nie zatrzyma się po hasło.

W każdym przypadku, w systemie z wieloma użytkownikami, być bardzo ostrożnym z SUIDponieważ może pozostawić miejsce na nadużycia uprawnień.