Odpowiedzi:
initctl --versionznajdź swoją aktualną wersję upstart.
Pytając na kanale #upstart na freenode, oficjalne stanowisko w tej sprawie brzmi:
W przyszłej wersji Upstart będzie dostępna natywna obsługa, ale na razie możesz użyć czegoś takiego:
exec su -s /bin/sh -c 'exec "$0" "$@"' username -- /path/to/command [parameters...]
suten sposób oznacza, że expect forknawet expect daemonnie łapią końcowego PID.
exec su -s /bin/sh -c 'HOME=/foo/bar exec "$0" "$@" &>/var/log/foobar.log' username -- /path/to/command [parameters...]
Co powiesz na użycie demona start-stop?
exec start-stop-daemon --start --chuid daemonuser --exec /bin/server_cmd
Z książki kucharskiej Upstart :
Zalecaną metodą dla systemów Debian i Ubuntu jest użycie narzędzia pomocniczego
start-stop-daemon. […]start-stop-daemonNie nakłada limitów PAM („wtykowego modułu uwierzytelniającego”) na proces, który rozpoczyna.
Uwaga: start-stop-daemonnie obsługiwane w RHEL.
Można to zrobić na kilka sposobów, wszystkie z nieco inną semantyką, szczególnie w odniesieniu do członkostwa w grupach:
setuidgid umieści cię w określonej grupie.
setuidgidumieszczą cię tylko w tej grupie, więc nie będziesz mieć dostępu do plików należących do innych grup, których jesteś członkiem.setuidgidz daemontools-encore, jak i setuidgidz zestawu narzędzi nosh mają opcję -s(aka --supplementary), która umieści cię w tej grupie, a także we wszystkich dodatkowych grupach dla określonego użytkownika.Używanie, newgrpgdy staniesz się mniej uprzywilejowanym użytkownikiem, doda pojedynczą grupę do zestawu grup, ale także utworzy nową podpowłokę, co utrudni korzystanie z niej wewnątrz skryptów.
start-stop-daemon zachowuje członkostwo w grupie i robi znacznie więcej niż tylko setuid / setgid.
chpst -u username:group1:group2:group3... commandnamepozwoli ci dokładnie określić, które członkostwa w grupach mają zostać przyjęte, ale (w Ubuntu ) jest dostarczany tylko z runitpakietem, który jest alternatywą dla upstart.
su -c commandname usernameodbiera wszystkie członkostwa w grupach użytkowników, podobnie sudo -u username commandnamejak oni, więc prawdopodobnie są drogą do najmniejszego zdziwienia.
Użyj setuidgidz paczki daemontools.
Dokumentacja tutaj: http://cr.yp.to/daemontools/setuidgid.html
W instancji Ubuntu 10.10 na Amazon EC2 miałem więcej szczęścia z start-stop-daemonpoleceniem.
Zmagałem się również z niektórymi innymi zwrotkami . Dzwonię do Pythona z określonym virtualenvi niektórymi parametrami do mojego uruchomionego programu.
Oto, co zadziałało dla mnie.
script
export PYTHONPATH=.:/home/ubuntu/.local/lib/python2.7/site-packages/:/home/ubuntu/python/lib/python2.7/site-packages/
exec start-stop-daemon --start --chuid ubuntu --exec /home/ubuntu/python_envs/MyProj/bin/python /home/ubuntu/www/MyProj/MyProj.py -- --config-file-dir=/home/ubuntu/www/MyProj/config/ >> /home/ubuntu/startup.log 2>&1 &
end script
Ma PYTHONPATHto na celu zainstalowanie niektórych pakietów ze źródła w ścieżce modułu PYTHON po uruchomieniu tego zadania upstart. Musiałem robić wszystko absolutnymi ścieżkami, ponieważ chdirzwrotka wydawała się nie działać.
Korzystałem z CentOS 6 i nie mogłem uzyskać zalecanego hacka (dla Upstart 0.6.5), ani też sztuczki „su”, ponieważ liczba zaangażowanych rozwidleń (chyba 4) nie była śledzona przez „spodziewać się widelca” ”lub„ expect demon ”.
W końcu właśnie to zrobiłem
chown user:group executable
chmod +s executable
(tj. ustaw bit setuid i zmień własność).
Może nie jest to najbezpieczniejsza metoda, ale w przypadku wewnętrznego projektu badawczo-rozwojowego w naszym przypadku nie miało to znaczenia.
chmod 1700a przynajmniej chmod u+sx,go-xtam, zamiast po prostu +s, kwalifikowałoby się to jako „wystarczająco bezpieczne”. :)
Istnieje trzecia możliwość, w zależności od tego, co próbujesz osiągnąć. Możesz być w stanie poluzować kontrolę dostępu do danych plików / urządzeń . Może to pozwolić nieuprzywilejowanemu użytkownikowi na montowanie lub uzyskiwanie dostępu do przedmiotów, do których normalnie nie mieliby dostępu. Tylko upewnij się, że nie rozdajesz kluczy do królestwa.
Możesz także zmienić limit czasu pamięci podręcznej haseł sudo . Ale nie polecam go, chyba że twoja maszyna jest fizycznie bezpieczna (tzn. Uważasz, że jest mało prawdopodobne, aby przechodzień próbował uzyskać dostęp do sudo).
Jest dobry powód, że istnieje bardzo niewiele sposobów wykonywania uprzywilejowanych działań i że wykonują one niepotrzebne konieczne rejestrowanie. Luźne ograniczenia byłyby zagrożeniem dla bezpieczeństwa twojego systemu, a brak rejestracji oznaczałby, że nie ma sposobu, aby dowiedzieć się, co się stało, gdy zostałeś zagrożony.
Jeśli problemem jest rozmiar plików dziennika, prawdopodobnie coś jest nie tak. Sudo generuje tylko jedną linię na użycie w normalnych warunkach.
W CentOS 6, na początku wersji 0.6.5, działało to dla mnie.
script
exec su user_name << EOF
exec /path/to/command [parameters...]
EOF
end script
lub:
script
exec su user_name << EOF
..... what you want to do ....
EOF
end script
Podczas użycia
exec su -s /bin/sh -c 'exec "$0" "$@"' username -- /path/to/command [parameters...]
proces pracy nie może zostać zatrzymany initclt stop. Myślę, że powodem jest:
1. the job forked and the main process is not tracked.
2. the main process changed its process group,because of `su -c`