2009-08-25 20 views
21

Wydaje mi się, że utknąłem między ograniczeniem NFS a ograniczeniem Crona.Jak uruchomić polecenie jako inny użytkownik niż root cronjob?

Więc mam root cron (na RHEL5), który uruchamia skrypt powłoki, który, między innymi, musi zsynchronizować niektóre pliki przez mount NFS. Pliki na podłączeniu NFS są własnością użytkownika apache z modułem 700, więc tylko użytkownik apache może uruchomić komendę rsync - działanie jako root powoduje błąd uprawnień (NFS jest rzadkim przypadkiem, gdzie użytkownik root jest nie wszystkie potężne?)

Kiedy chcę tylko uruchomić rsync ręcznie, mogę użyć "sudo -u apache rsync ..." Ale sudo no workie in cron - mówi "sudo: sorry, you musi mieć tty do uruchomienia sudo ".

Nie chcę uruchamiać całego skryptu jako apache (to znaczy z crontab apache'a), ponieważ inne części skryptu wymagają korzenia - to tylko jedno polecenie, które musi działać jako apache. I naprawdę wolałbym nie zmieniać trybu plików, ponieważ spowoduje to znaczące zmiany w innych aplikacjach.

Musi być sposób na wykonanie "sudo -u apache" z cron?

dziękuję! rob

+1

Może być lepiej obsługiwana przez przeniesienie tego do SuperUser.com. – Robert

+0

To jest stare pytanie, ale wciąż znajduje się dość wysoko w rankingach, a żadna z odpowiedzi nie wyjaśnia, dlaczego uprawnienia root'a nie miały zastosowania do mount NFS. Dla każdego, kto się o to potyka, powodem jest root_squash. Ten blog ma całkiem przyzwoite wyjaśnienie, dlaczego ta opcja jest konieczna i zazwyczaj jest ustawiona domyślnie. http://fulautolinux.blogspot.com/2015/11/nfs-norootsquash-and-suid-basic-nfs.html – BryKKan

Odpowiedz

7

Zastosowanie su zamiast sudo:

su -c "rsync ..." apache 
+1

Tak! Ale nie. Użytkownik apache nie ma zwykłej powłoki logowania, więc składnia su -c zwraca tylko "To konto jest obecnie niedostępne". A zmiana hasła passwd użytkownika apache w tym celu wydaje się złym pomysłem. Hm, myślę, że to pytanie powinno być zatytułowane "Jak uruchomić polecenie jako użytkownik apache z root cronjob?" A może nie da się tego zrobić bez wprowadzenia luk w zabezpieczeniach? – rob

+5

Czy to pomaga, jeśli jawnie określasz powłokę, która ma być używana z przełącznikiem '-s' (na przykład' -s/bin/sh')?Przynajmniej na Ubuntu wydaje się to pomocne, jeśli dany użytkownik nie ma poprawnej powłoki w/etc/passwd. –

+0

@JukkaMatilainen - Tak, który działał dla mnie również w ubuntu. – runamok

1

miejsce w katalogu/etc/crontab i określić apache zamiast root w polu użytkownika

+0

Nie działa na moim Debianie 6. –

17

su --shell =/bin/bash - , Polska ks-command = "/ path/to/command -argument = coś" username &

pracuje dla mnie (CentOS)

+0

Musiałem dodać 'export TERM = xterm;' przed moim poleceniem wewnątrz zmiennej '--session-command'. Tak więc skończyło się na 'su --shell =/bin/bash --session-command =" export TERM = xterm;/path/to/command -argument = something "username &' –

+0

Nie działa w systemie Ubuntu (12.04), ponieważ polecenie 'su' nie obsługuje opcji' --session-command'. – Lambart

+0

aby wyjaśnić odpowiedź, w crontabu root, dodaj 'su --shell =/bin/bash --session-command ="/path/to/command -argument = something "username' – NoelProf

1

Jeśli chcesz trwale pozwalają bawić się wokół jak Apache:

chsh apache 

to pozwala aby zmienić powłokę dla użytkownika

Powiązane problemy