Czy potrzebuję dedykowanego użytkownika Linuksa do zaplanowanych zadań?


1

Powiedzmy, że mam skrypty bash do tworzenia kopii zapasowych / synchronizacji / pobierania z Internetu / zadań aktualizacji. Zamierzam je uruchomić zgodnie z harmonogramem z crontabem. Czy bezpiecznie jest tworzyć crontab dla roota, czy też potrzebuję dedykowanego użytkownika Linuksa? A jeśli tego potrzebuję, dlaczego?

UPD: W rzeczywistości istnieją trzy opcje: 1) root - Ok. To zła opcja. 2) istniejący użytkownik. 3) dedykowany użytkownik.

Czy oddany użytkownik jest lepszy od istniejącego (np. Właściciel stacji roboczej, zwykły użytkownik)? Biorąc pod uwagę, że nie mogę utworzyć dedykowanego użytkownika nologin, ponieważ używam rsync przez ssh i będę musiał dodać nowego użytkownika na zdalnym komputerze, z którym synchronizuję.


Wystarczy wspomnieć o jednym zagrożeniu bezpieczeństwa, jeśli DNS jest w jakiś sposób narażony na szwank, pobierzesz potencjalnie zagrażający skrypt. Byłbyś tak szczęśliwy, że nie użyłeś roota. Rozważ też użycie /bin/falsetego użytkownika jako powłoki.
vfsoraki

Tak. Zrobiłem użytkownika nologin na komputerze, na którym działa cronjob. Zamierzam zmienić powłokę logowania użytkownika na ograniczoną na zdalnym serwerze.
Wsiewołod

Odpowiedzi:


3

To zawsze lepiej, aby uruchomić rzeczy jako użytkownik inny niż root z dokładnie taką samą dostępu i uprawnień, ile potrzebuje, i nic więcej.

To, czy uruchomienie „roota” jest „bezpieczne”, zależy od tego, co robi ( echo „”> / dev / null wydaje się względnie nieszkodliwe :)), ale zawsze jest mniej bezpieczne niż uruchamianie go jako użytkownik inny niż root, ponieważ ty nigdy nie wiadomo, jakiej ewentualności możesz przeoczyć, gdzie coś może wpłynąć na coś, na co nie powinno mieć wpływu.

Oto coś, co mi się przydarzyło raz, na przykład: co jeśli przypadkowo napiszesz niebezpieczne polecenie bash do pliku skryptu przez awarię kopiowania, w której skopiowałeś część swojej historii bash do skryptu (który na przykład zawiera trochę rm -rf polecenie na ścieżce względnej, zamiast wierszy z postu superużytkownika z przykładowym kodem). Czy byłem szczęśliwy, że uruchomiłem cronjob pod właściwym użytkownikiem :) Teraz wszystko, co się stało, polegało na tym, że konfiguracja git tego użytkownika została utracona ...


Cześć, SadBunny. Tak, też to miałem: kilka razy odetchnąłem z ulgą, gdy zobaczyłem: can't remove .. permission deniedw moim przypadku były to najczęściej złe filtry do polecenia rm. Ale chcę rozważyć inną opcję: działanie jako istniejący użytkownik, ponieważ mam ten dylemat do automatyzacji stacji roboczych. Czy możesz sprawdzić zaktualizowane pytanie?
Wsiewołod

Cóż, te same rzeczy obowiązują mniej więcej, dedykowany użytkownik jest oczywiście bezpieczniejszy, ponieważ co jeśli zapomnisz o cronjobie 6 miesięcy później, gdy zmienisz coś w istniejącym użytkowniku, może tymczasowo nadasz mu więcej praw, zmienisz klucze ssh lub może to całkowicie usunąć ... Ryzyko jest oczywiście mniejsze niż używanie roota, więc jeśli są to twoje opcje i czujesz, że oddany użytkownik wymaga pochylenia się zbyt daleko, to na pewno. Widziałem siebie, jak poszedłem na ten kompromis, chociaż nikomu nie powiedziałbym :)
SadBunny,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.