Требуется ли перезагрузка для обновления разрешений после добавления пользователя в новую группу?

На сервере Ubuntu я уже не раз замечал, что после добавления пользователя в группу этот пользователь не имеет прав доступа к группе до перезагрузки системы. Например:

Пользователю 'hudson' требуется разрешение на чтение каталога 'root: shadow / etc / shadow', поэтому я добавляю hudson в группу shadow. Хадсон до сих пор не умеет читать. Итак, я 'sudo shutdown -h -r now' и когда система снова запускается, пользователь hudson может читать.

Требуется ли перезагрузка или есть лучший способ применить разрешения после добавления пользователя в группу?

Я искал решение, наткнулся на этот пост, а потом нашел его!

Я думал, что на самом деле предложу решение, чтобы другие могли выиграть. Вход и выход так 1995.

Взято из:

https://arkaitzj.wordpress.com/2010/03/08/linux-add-user-to-a-group-without-logout/

Поэтому, если вам нужно было получить разрешения для cdromгруппы, вы просто добавили своего пользователя в:

newgrp cdrom 

например

Так что шаги будут:

#adduser my_user cdrom

а потом

$newgrp cdrom

Я подтвердил, что это работает.

Простая $groupsпроверка из CLI показывает, что пользователь находится в группе. И быстрое выполнение с необходимыми привилегиями из этой группы работает.

Не нужно убивать ваши окна и войти и выйти! Надеюсь, что это помогает другим!

Дополнительная информация (на основе полезного комментария jytou): «[Это] решение будет работать только для текущей открытой оболочки. Если у вас открыта другая оболочка, вам нужно будет использовать ту же команду для учета изменений».

При добавлении пользователя в новую группу пользователь должен выйти из системы и снова войти в нее, чтобы она вступила в силу. Хотя перезагрузка это сделает, этого не требуется.

Добавление пользователя в группу не влияет на зарегистрированных пользователей.

В случае демона, вам нужно перезапустить его для применения новых групп.

Кроме того, перезапуск демона с использованием параметра в самом демоне не будет работать, поскольку он унаследует текущую среду.

Самый простой способ заставить его работать, это полностью остановить демон и запустить его снова, как в ..

/etc/init.d/foo stop ; /etc/init.d/foo start

это намного проще, вы можете проверить текущий уровень доступа, набрав:

id

для перезагрузки ваших групп вам просто нужно:

su - $USER

после этого снова проверьте уровень доступа:

id

и вы увидите, что новая группа теперь активна.

Существует другой режим сбоя, который также следует учитывать здесь.

Если администратор обновил, /etc/groupно не смог обновить /etc/gshadow(в системах с такой настройкой), выход из системы и повторный вход фактически не назначат вас в новую группу.

Смущает, groupsпокажет вам реальную, текущую ситуацию, в то время как idнеправильно напечатает вывод, который указывает, что вы правильно являетесь членом группы.

tripleee@vbvntv$ groups
tripleee

tripleee@vbvntv$ id
uid=1234(tripleee) gid=1234(tripleee) groups=1234(tripleee),4(adm)

tripleee@vbvntv$ ls -l /var/log/mail.log
-rw-r----- 1 root adm 15728 May 26 14:26 /var/log/mail.log

tripleee@vbvntv$ tail /var/log/mail.log
tail: cannot open `/var/log/mail.log' for reading: Permission denied

Я не могу использовать, newgrpпотому что он запрашивает пароль, и у меня нет пароля, только аутентификация с открытым ключом SSH.

Решением было бы для администратора отменить ручное редактирование /etc/groupsи затем сделать это снова sudo gpasswd -a tripleee adm; или, альтернативно, использовать grpconvдля слияния изменений (которые я взял с /server//a/389719/98333 )