Jak skonfigurować pkexec, aby nie pytał o hasło?

Mam aplikację GUI, która musi wywoływać demona (napisanego w języku Python) z uprawnieniami administratora. Chciałbym to zrobić bez pytania użytkownika o hasło.

Ponieważ demon jest skryptem, nie mogę ustawić bitu SUID bezpośrednio. Mógłbym do tego napisać opakowanie C, ale wolałbym nie wymyślać na nowo koła, zwłaszcza gdy błąd z mojej strony może poważnie zagrozić bezpieczeństwu systemu.

Zwykle w tej sytuacji dodam wiersz, /etc/sudoersktóry pozwala użytkownikom uruchamiać demona jako root bez hasła, przy użyciu dyrektywy NOPASSWD. Działa to dobrze z wiersza poleceń. Jednak gdy robię to z GUI, pkexecpojawia się okno dialogowe z pytaniem o hasło użytkownika. Wygląda na to, że w Ubuntu połączenia sudoz GUI są w jakiś sposób przechwytywane pkexec.

Czy jest na to czysty sposób? Naprawdę wolałbym nie mieć do czynienia z kłopotami ze skryptem setuid.

— Chinmay Kanchi
źródło

O jakiej aplikacji mówisz?

— Radu Rădeanu,

Dowolna aplikacja GUI. Gdy aplikacja GUI próbuje się uruchomić sudo somecommand, pojawia się pkexecokno dialogowe z hasłem, niezależnie od tego, czy istnieją zasady sudoers umożliwiające wykonywanie programu.

— Chinmay Kanchi,

Niewłaściwe jest powiedzenie: „Wygląda na to, że w Ubuntu połączenia sudoz GUI są w jakiś sposób przechwytywane pkexec” . pkexecnie ma wiele wspólnego z sudo. W przeciwieństwie do sudo, pkexecnie przyznaje uprawnień rootowi całemu procesowi, ale pozwala na dokładniejszy poziom kontroli scentralizowanych zasad systemowych.

Teraz, jeśli chcesz uruchomić aplikację GUI bez podania hasła pkexec, nie jest to trudne. Weźmy na przykład GParted . Po otwarciu zobaczysz następujące okno dialogowe z pytaniem o hasło:

uwierzytelnianie gparted

Kliknij Szczegóły, a okno dialogowe będzie teraz wyglądać następująco:

uwierzytelnianie gparted - szczegóły

Stąd wszystko, co musisz zrobić, to otworzyć plik, używając na przykład następującego polecenia:/usr/share/polkit-1/actions/com.ubuntu.pkexec.gparted.policy

gksu gedit /usr/share/polkit-1/actions/com.ubuntu.pkexec.gparted.policy

i zmień następujące linie:

      <allow_any>auth_admin</allow_any>
      <allow_inactive>auth_admin</allow_inactive>
      <allow_active>auth_admin</allow_active>

z następującymi:

      <allow_any>yes</allow_any>
      <allow_inactive>yes</allow_inactive>
      <allow_active>yes</allow_active>

Zapisz plik i zamknij go. Następnie, kiedy otworzysz GParted , nie będziesz już proszony o hasło.

— Radu Rădeanu
źródło

Tak, pkexec rzeczywiście przechwytuje połączenia z sudo. Pokażę, czy mogę zbudować minimalny przykład tego zachowania.

— Chinmay Kanchi,

Nie mogę tego powtórzyć w prostej aplikacji, może się to zdarzyć tylko w niektórych bardzo specyficznych sytuacjach i nie mam czasu na śledzenie błędu. Przyjmuję twoją odpowiedź. Twoje zdrowie.

— Chinmay Kanchi,

@ChinmayKanchi Bądźmy bardziej klarowni. Wezmę na przykład jeszcze raz gparted. Podczas uruchamiania z terminala sudo gparteduruchamiany jest /usr/sbin/gpartedplik z uprawnieniami administratora. Kiedy zaczynasz gpartedz GUI, zaczynasz w rzeczywistości gparted-pkexec(możesz zweryfikować ten /usr/share/applications/gparted.desktopplik wewnętrzny ), czyli /usr/bin/gparted-pkexecskrypt powłoki, którego celem jest uruchomienie następującej komendy: pkexec "/usr/sbin/gparted"co jest równoważne z pkexec gparted. Więc nie ma z tym nic wspólnego sudo. A tego polecenia nie powinieneś używać w terminalu sudo gparted.

— Radu Rădeanu,

@ChinmayKanchi sudopowinno być używane tylko w aplikacjach powłoki, a nie aplikacjach GUI. Zobacz man sudoi man pkexecw tym sensie.

— Radu Rădeanu,

Tak, znam oba twoje punkty. Moja sytuacja jest taka, że mam aplikację GUI (napisaną przeze mnie), która próbuje uruchomić program powłoki (demona, również napisany przeze mnie) przy użyciu sudo. Z jakiegoś powodu powoduje to wywołanie pkexec zamiast sudo, co oznacza, że wszelkie zasady sudo, które utworzyłem dla demona, zostaną zignorowane.

— Chinmay Kanchi,