Załaduj ponownie zadania grupy użytkowników systemu Linux bez wylogowania

Podczas przypisywania listy grup drugorzędnych użytkownika za pomocą:

# usermod -G <grouplist> <user>

czy można wymusić, aby to przypisanie grupy zaczęło obowiązywać bez wylogowywania się z wszystkich uruchomionych sesji?

Byłoby to bardzo przydatne w sytuacji, gdy istnieje sesja Screen z wieloma uruchomionymi powłokami, ponieważ zasadniczo cała sesja musi zostać zniszczona, aby przypisanie do grupy stało się skuteczne.

Myślę, że mogę zmienić grupę podstawową użytkownika w działającej powłoce za pomocą newgrppolecenia - czy istnieje jakaś alternatywa, która działałaby dla grup drugorzędnych?

Idealnie chciałbym mieć coś, co zadziałałoby w każdej powłoce bez uruchamiania w każdej z nich ręcznie, ale w przeciwnym razie, może jakiś sposób zmuszenia Screena do wykonania tego samego polecenia w każdej z nich.

Okropnie hacky, ale możesz użyć dwóch warstw, newgrpaby osiągnąć to dla konkretnej grupy:

id -g

... poda bieżący identyfikator grupy podstawowej. Nazwiemy to orig_groupna potrzeby tego przykładu. Następnie:

newgrp <new group name>

... przełączy Cię do tej grupy jako podstawowej i doda ją do listy grup zwróconych przez groupslub id -G. Teraz kolejne:

newgrp <orig_group>

... dostaniesz powłokę, w której możesz zobaczyć nową grupę, a podstawową jest ta oryginalna.

Jest to okropne i powoduje, że dodawana jest tylko jedna grupa na raz, ale pomogło mi to kilka razy, aby dodać grupy bez wylogowania / w całej mojej sesji X (np. Aby dodać bezpiecznik jako grupę do użytkownika aby sshfs działał).

Edycja: Nie wymaga to również wpisania hasła, co suspowoduje.

Z poziomu powłoki możesz wydać następujące polecenie

su - $USER

id wyświetli teraz nową grupę:

id

Ta fajna sztuczka z tego linku działa świetnie!

exec su -l $USER

Pomyślałem, że opublikuję go tutaj, ponieważ za każdym razem, gdy zapominam, jak to zrobić, jest to pierwszy link, który pojawia się w Google.

1. Uzyskiwanie powłoki z nową grupą bez wylogowania i ponownego zalogowania

Jeśli dodajesz tylko jedną grupę, użyłem następujących:

exec sg <new group name> newgrp `id -gn`

Jest to odmiana dwuwarstwowej sztuczki newgrp Legooolas, ale jest w jednym wierszu i nie wymaga ręcznego wprowadzania grupy podstawowej.

sgjest newgrp, ale przyjmuje polecenie wykonania z nowym identyfikatorem grupy. Te execśrodki, że nowa powłoka zastępuje istniejącą powłokę, dzięki czemu nie trzeba „wylogowania” dwukrotnie.

W przeciwieństwie do su, nie musisz wpisywać swojego hasła. Nie odświeża również twojego środowiska (oprócz dodawania grupy), więc zachowujesz swój bieżący katalog roboczy itp.

2. Wykonanie polecenia we wszystkich oknach ekranu w sesji

atKomenda w ekran uruchamia polecenie w cokolwiek okna można określić (zauważ, że jest to polecenie ekranu, a nie polecenie powłoki).

Możesz użyć następującego polecenia, aby wysłać polecenie do wszystkich istniejących sesji Screen:

screen -S <session_name> -X at \# stuff "exec sg <new_group_name> newgrp \`id -gn\`^M"

Zwróć uwagę na potrzebę ucieczki przed backstickami, aby iduruchomić w sesji Screen, oraz ^ M, aby Screen uderzył „enter” na końcu twojego polecenia.

Zauważ też, że stuffpolecenie screena po prostu wpisuje tekst polecenia w twoim imieniu. Dlatego może się zdarzyć coś dziwnego, jeśli jedno z okien ekranowych ma w połowie napisane polecenie w wierszu polecenia lub uruchamia aplikację inną niż powłoka (np. Emacs, top). Jeśli to jest problem, mam kilka pomysłów:

• Aby pozbyć się w połowie napisanego polecenia, możesz dodać „^ C” na początku polecenia.
• Aby uniknąć uruchamiania polecenia w oknie emacsa itp., Możesz poprosić `at 'o filtrowanie według tytułu okna itp. (W powyższym przykładzie używam„ # ”, który pasuje do wszystkich okien, ale możesz filtrować według tytułu okna, użytkownika itp.).

Aby uruchomić polecenie w określonym oknie (oznaczonym numerem okna), użyj następujących poleceń:

screen -S <session_name> -p 0 -X stuff "exec sg <new_group_name> newgrp \`id -gn\`^M"

Za pomocą newgrppolecenia rozwiązał problem dla mnie:

newgrp <GroupName>

Ten post na blogu zawiera szczegółowe wyjaśnienia.

Grupy są zwykle wyliczane przy logowaniu, nie ma sposobu, aby zmusić je do ponownego wykonania wyliczenia grup bez wylogowania i ponownego zalogowania.

Wydaje się, że w wielu głosowaniach tutaj zastosowano obejście, które wywołuje nową powłokę ze świeżym środowiskiem (tak samo jak ponowne logowanie). powłoka nadrzędna i wszystkie inne stale działające programy na ogół nie otrzymają nowego członkostwa w grupie, dopóki nie zostaną ponownie wywołane ze świeżej powłoki, zwykle po czystym wylogowaniu i zalogowaniu.

Możesz to zrobić.

Dodaj tyle grup, ile chcesz usermod -G. Następnie jako użytkownik z uruchomioną sesją uruchom newgrp -tylko argument „-”.

Powoduje to ponowne ustawienie identyfikatora grupy na wartość domyślną, ale spowoduje także ustawienie grup pomocniczych. Możesz to sprawdzić, uruchamiając groupsz bieżącej sesji, przed i po usermodoraz newgrp.

To musi być uruchamiane z każdej otwartej sesji - niewiele wiem o ekranie. Jeśli jednak można iterować wszystkie otwarte sesje i biegać newgrp, powinieneś być dobry. Nie musisz się martwić o znajomość grup lub identyfikatorów grup.

Powodzenia.

Podsumowując:

exec newgrp <newlyaddedgroupname1>
exec newgrp <newlyaddedgroupname2>
...
exec newgrp -

Użycie „exec” oznacza zastąpienie istniejącej powłoki nową powłoką uruchomioną przez komendę newgrp (więc wyjście z nowej powłoki powoduje wylogowanie).

Wersja ostateczna newgrp -jest potrzebna do przywrócenia normalnej grupy podstawowej, więc pliki, które później utworzysz, będą miały tego właściciela.

Uwaga: pytanie oryginalnego plakatu brzmiało, jak sprawić, by nowo dodane grupy były widoczne w istniejących procesach. gpasswdI usermodpolecenia nie wpływa na istniejące procesy; nowo dodane (lub usunięte!) grupy pojawiają się w (znikają) z twojego konta, tj. w plikach / etc / group i / etc / gshadow, ale uprawnienia dla istniejących procesów nie są zmieniane. Aby usunąć uprawnienia, musisz zabić wszystkie uruchomione procesy; newgrp -nie odczyta ponownie pliku / etc / group i nie zresetuje listy grup; zamiast tego wydaje się po prostu korzystać z grup wcześniej powiązanych z procesem.

Miałem podobny problem, ale także dla niezalogowanych użytkowników. Restart nscd nie pomogło, ale wykonanie tego polecenia nie: nscd -i group. To powinno poinstruować nscd (demona buforowania), aby ponownie załadował plik grup.

Nie mogłem uruchomić polecenia newgrp. Nie jestem pewien, czy zależy to od / etc / sudoers, ale zwykle muszę wpisać hasło do sudo, i działało to bez wymagania hasła:

[leo60228@leonix:~]$ groups
users wheel

[leo60228@leonix:~]$ sudo echo hi
[sudo] password for leo60228:
hi

[leo60228@leonix:~]$ sudo -k # reset sudo timeout

[leo60228@leonix:~]$ exec sudo -i -u $(whoami) # no password necessary

[leo60228@leonix:~]$ groups
users wheel docker

To załatwia sudosprawę, jeśli masz, i może uchronić Cię przed ponownym wprowadzeniem hasła w niektórych przypadkach:

sudo su $USER