Uruchamianie zadań upstart jako nieuprzywilejowani użytkownicy

Jaki jest kanoniczny sposób, aby zlecenie upstart zmieniło swój identyfikator użytkownika i uruchomiło skrypt jako użytkownik nieuprzywilejowany?

Oczywiście można użyć sulub sudo, ale wydaje się to hacking (i może generować niepotrzebne linie dziennika).

W wersji 1.4 1.4 setuid i setgid są obsługiwane natywnie w pliku konfiguracyjnym.

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...]

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.

  • Oryginalne narzędzia daemontools 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.
  • Zarówno 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.

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`