Sudo jako inny użytkownik i ekran do biegania

167

Dowiedziałem się dzisiaj, że ekran do uruchamiania jako inny użytkownik, do którego sudo się włącza, nie będzie działał!

to znaczy

ssh bob@server         # ssh into server as bob
sudo su "monitor" -
screen                 # fails: Cannot open your terminal '/dev/pts/0'

Mam skrypt działający jako użytkownik „monitora”. Uruchamiamy go w sesji ekranowej, aby zobaczyć wynik na ekranie. Problem polega na tym, że mamy wielu użytkowników, którzy logują się na swoje własne konta (np. Bob, James, Susie itp.), A następnie sudo do użytkownika „monitorującego”. Zapewnienie im dostępu do użytkownika „monitorującego” nie wchodzi w rachubę.

sudo gnu-screen

— luckytaxi
źródło

13

Czy to błąd, który otrzymujesz? „Nie można otworzyć terminala” / dev / pts / 0 ”- sprawdź.”

— Jim

tak to jest to. Rozumiem, dlaczego tak się dzieje, ale czy istnieje obejście?

— luckytaxi

4

Komentarz do twoich poleceń - ciągle widzę ludzi biegających sudo su "user" -. Dlaczego nie użyć sudo -u user -s?

— Andrew Aylett,

2

@Jim: +1 za dostarczenie brakującego komunikatu o błędzie.

— Dennis Williamson,

1

@Andrew Większość facetów, których znam sudo su- myślę, że ludzie po prostu się do tego przyzwyczaili (w moim przypadku dzieje się tak dlatego, że nie musisz znać żadnych flag sudo sudo su- nie sądzę, żebym kiedykolwiek przeczytał stronę sudo :)

— voretaq7

245

Spróbuj uruchomić się script /dev/nulljako użytkownik suprzed uruchomieniem ekranu - to mały hack w getcie, ale powinien uszczęśliwić ekran.

— voretaq7
źródło

5

Re: konsekwencje dla bezpieczeństwa, nie jestem tego świadomy (ale to nie znaczy, że ich nie ma :) - IIRC polega na skutku ubocznym „skryptu” otwierającego nowe urządzenie końcowe (jak wywołuje to użytkownik) , a ponieważ wysyłasz wyniki skryptu do / dev / null, nie ma nic do przechwycenia. Jest to również zdecydowanie bezpieczniejsze niż dodawanie użytkowników do grupy tty (IMHO)

— voretaq7

2

@nalply Szczerze mówiąc, nie powinieneś uważać wielu powłok za mylące, jeśli jesteś administratorem systemu uniksowego - to powiedziawszy, scriptmoże być użyte do uruchomienia screen. Następnie musisz wyjść tylko dwa razy (raz dla screen, raz dla su). (Jest to coś, co scriptstrona podręcznika może dla ciebie wyjaśnić, jeśli poświęcisz trochę czasu na jej przeczytanie ...)

— voretaq7

10

Lub po prostu biegnij sudo -u bob script -q -c 'screen -dr myscreen' /dev/null. Masz tylko jeden terminal, z którego można wyjść / odłączyć.

— Andy Shulman

4

Dzięki, to mnie uratowało. Ale dlaczego to naprawia? Z tego, co rozumiem, drukuje wszystko od standardowego do ... nigdzie. I to w jakiś sposób naprawia ekran.

— sudo

3

@sudo Aby to zrobić, scriptotwiera własne urządzenie tty, należące do użytkownika, który je uruchomił (zajrzyj, /deva zobaczysz, że pojawi się po uruchomieniu script). screennastępnie pobiera to urządzenie tty (które jest własnością uruchomionego użytkownika, screenwięc nie ma problemów z dostępem do niego). To totalna robota hakerska, ale działa. Patrząc na niektóre z moich maszyn, wydaje się, że nowe wersje ekranu wydają się instalować setuid-root, co również działa, ale oznacza, że masz innego binarnego setuida-roota, co sprawia, że niektórzy ludzie są niekomfortowo nieswojo.

— voretaq7

33

Korzystam z funkcji otoki screendla użytkowników, których używam sudo su. To jest funkcja otoki, którą dodałem do użytkownika ~/.bashrc:

ekran funkcji () {
  / usr / bin / script -q -c "/ usr / bin / screen $ {*}" / dev / null
}

To pozwala mi korzystać ze wszystkich opcji i parametrów screen, których mógłbym chcieć użyć. Zastanawiam się nad wprowadzeniem tej funkcji w całym systemie.

— steviethecat
źródło

1

Działa świetnie. Dla tych, którzy chcą tego systemu, polecam dodanie tego do /etc/bash.bashrc - działa u wszystkich użytkowników.

— Someguy123

2

Nie będzie to podawać argumentów do poprawnego sprawdzenia, w przeciwnym razie dobre rozwiązanie.

— sierpnia

7

Zakładając, że i tak są one połączone z hostem SSH, możesz dodać publiczne klucze ssh dla każdego użytkownika, który potrzebuje dostępu do konta monitora w pliku ~ monitor / .ssh / Author_keys. Następnie na zdalnym komputerze każdego użytkownika mogą działać

ssh -t monitor@remote.machine screen -RD

— Alex
źródło

Jest to kolejne dobre podejście - trzeba by jednak podać wymuszone polecenia w pliku autoryzowanych kluczy (według szczęściaytaxi „udzielenie im dostępu do użytkownika„ monitora ”nie wchodzi w rachubę” uwaga powyżej - wymuszone polecenia mogą ograniczyć je tylko do dołączanie sesji ekranowej)

— voretaq7

2

Nie byłem pewien, jak rozwiązać ten problem w mojej odpowiedzi, ponieważ powiedział, że „udzielenie im dostępu ... nie wchodzi w rachubę”, ale powiedział także „… sudo do użytkownika„ monitorującego ”. Ale zgadzam się, że należy się tym zająć, wymuszając ograniczenie poleceń w uprawnionych kluczach.

— Alex

7

Zakładając, że mówimy o tym błędzie:

$ sudo su - bob
$ screen
Cannot open your terminal '/dev/pts/5' - please check.

Oto jedna linijka (na przykład może być używana jako „alias gobob”):

sudo su - bob -c "script -c bash /dev/null"'

Wyjaśnienie:

To uruchomi powłokę (jak powłokę logowania) jako bob użytkownika. Uruchamia się bob użytkownika script, który ma wywołać bash (może to być myślnik lub ksh ...), a kopia sesji zostaje wyrzucona.

— podstawowy 6
źródło

0

Prawdopodobnie musiałaby zmienić uprawnienia na danym urządzeniu lub dodać monitor do grupy, która ma pozwolenie na odczyt tego urządzenia, byłoby to moją pierwszą skłonnością. Ale musiałbyś rozważyć konsekwencje bezpieczeństwa.

— Bart Silverstrim
źródło

0

Mówisz, że robisz:

sudo su "monitor" -

Zastanawiam się nad końcową kreską. Zwyklę robię:

sudo su - username

Myślnik (na stronie podręcznika użytkownika su) mówi su, aby „uczynił powłokę powłoką logowania”. Oznacza to, że pozyska wszystkie zwykłe skrypty startowe powłoki i odpowiednio skonfiguruje takie rzeczy, jak PATH i HOME.

— Doug Harris
źródło

3

Nie. sudo su - usernamei sudo su username -rób to samo.

— Tim Ludwinski,

-4

Właśnie trafiłem w ten problem. Rozwiązałem to chmod +rw $(tty)przed uruchomieniem sudo. Problem z tym rozwiązaniem polega na tym, że każdy może potem połączyć się i węszyć na twoim terminalu.

— Amos Shapira
źródło

2

Brzmi jak świetne rozwiązanie.

— Evan Carroll,

10

@EvanCarroll To świetne rozwiązanie, z wyjątkiem tej części, w której cały świat ma dostęp do odczytu i zapisu na swoim terminalu. Drobny problem z bezpieczeństwem - żaden program nie przejmowałby się tym, z wyjątkiem oczywiście wszystkiego, co sprawdza bezpieczeństwo terminala przed zaakceptowaniem haseł ( gpgna przykład). I na pewno nigdy nie będzie w systemie ze złośliwymi użytkownikami, którzy będą oglądać ttyi wąchać hasła ...

— voretaq7

Uwaga : nigdy nie próbuj tego w domu! to jest niebezpieczne!!!

— ruizpauker