Czy skrypty wymagające sudo powinny zawieść, jeśli go nie mają, czy użyć sudo i monitu?

Mam skrypt, który daje mi precyzyjną kontrolę nad jasnością podświetlenia i wymaga sudouruchomienia. Zasadniczo jest to:

backlight="/sys/class/backlight/acpi_video0/brightness"
echo $1 | tee $backlight

i mieszka w ~/bin/backlight-adjust. Skrypt potrzebuje sudouprawnień, ponieważ tee $backlightpisze w uprzywilejowanej lokalizacji. Więc zawiedzie, jeśli nie będzie działać sudo.

Podejście to ma problem, bo nie mogę po prostu uruchomić sudo backlight-adjust, ponieważ ~/binnie jest w $PATHw sudośrodowisku, tylko w moim otoczeniu. Więc musiałbym biec sudo env "PATH=$PATH" backlight-adjustlub coś podobnego.

Ewentualnie mógłbym napisać to w ten sposób:

backlight="/sys/class/backlight/acpi_video0/brightness"
echo $1 | sudo tee $backlight

i zapytaj mnie o hasło.

Drugie podejście działa dla mnie lepiej, ponieważ nie muszę pamiętać o pisaniu sudo; zachęci mnie. I mogę zachować moje $PATHnienaruszone. Jest to ogólnie wygodniejsze, ale czy są jakieś powody, dla których nie powinienem tego robić w drugą stronę?

(Używam Xubuntu 14.04, a moją powłoką jest GNU bash 4.2.45, jeśli to robi różnicę).

Osobiście zastosowałbym inne podejście. Utwórz alias dla swojego skryptu. Dodaj ten wiersz do swojej ~/.bashrc(lub równoważnej w innych powłokach)

alias backlight-adjust='sudo ~/bin/backlight-adjust'

W ten sposób nie musisz się martwić pamięcią o uruchomieniu go sudoi nie musisz dodawać sudoskryptu. Będzie dla ciebie całkowicie przejrzysty i po prostu poprosisz o hasło podczas próby uruchomienia backlight-adjust.

Nie rozumiem, dlaczego może to być niepoprawne --- chociaż zwykle wolę, aby polecenia nie pytały mnie o to, aby można je było pisać. Możesz dostosować, /etc/sudoersaby sudodziałał bez hasła.

Ale ... dlaczego nie dodać

chgrp  one-of-your-groups-here /sys/class/backlight/acpi_video0/brightness     
chmod g+w /sys/class/backlight/acpi_video0/brightness 

w swoim /etc/rc.locali zapominasz o sudo?

(W Ubuntu, jeśli możesz używać, sudojesteś w grupie sudo , więc możesz korzystać z niego chgrp sudo /sys...i być z niego zadowolonym.)

Możesz też dodać

Defaults        env_keep +="PATH"

do twojego /etc/sudoerspliku.

Stwierdzasz, że sudo dostosowuje podświetlenie, ponieważ ~ / bin nie znajduje się w zmiennej $ PATH w środowisku sudo

Dlaczego więc na tym polegać? Myślę, że powinieneś po prostu zmienić tę linię na /home/user/bin/backlight-adjusti to zadziała.

Ale naprawdę chciałbym, żeby Terdon również używał aliasu. Lub możesz umieścić swój skrypt /usr/bin/i będzie on dostępny dla każdego użytkownika (w tym root)

Nie można podać ogólnej zasady ... jeśli skrypt / program jest zaprojektowany do przeprowadzenia ponownej konfiguracji (np. Drukarki) i jest wywoływany przez zwykłych użytkowników, musi to zrobić. W przeciwnym razie zostawiłbym wystarczająco dobrze w spokoju: jeśli zwykły użytkownik go uruchomi, po prostu się nie powiedzie (albo w wyniku wyraźnej kontroli, albo po prostu dlatego, że nie wolno mu nic zrobić).

Podwyższone przywileje powinny być wydawane oszczędnie, jeśli w ogóle. Przejście na wyższy poziom uprawnień jest trudne, lepiej pozostaw to ekspertom (tj sudo(1).).

Osobiście używam czegoś takiego jak ${SUDO}w moich skryptach, aby osoba dzwoniąca mogła to ustawić w razie potrzeby lub ${SUDO:-sudo}użyć domyślnie.

W twoim konkretnym przypadku jestem jednak z zaakceptowaną odpowiedzią.

Umieść skrypt (bez sudo) w odpowiedniej lokalizacji dla całego użytkownika, na przykład /bin, a następnie wykonaj następujące czynności:

sudo chown root /bin/backlight-adjust
sudo chmod 4755 /bin/backlight-adjust

Działa to poprzez ustawienie flagi setuid, co oznacza, że ​​zawsze będzie uruchamiana jako właściciel pliku. Szczegółowe informacje można znaleźć na stronie http://major.io/2007/02/13/chmod-and-the-mysterious-first-octet/ . Tak naprawdę nie wiem aż tak bardzo o tym, jak to działa, po prostu znalazłem googlowanie na podstawie czegoś, co przeczytałem kilka lat temu.