Linux: группы против групп

Кто-нибудь знает, почему команда Linux

    groups 

показывает другой вывод, чем

    groups username 

Зарегистрированный пользователь совпадает с параметром username. Пример:

    thorsten@ubuntu:~/tmp$ groups
    thorsten adm dialout cdrom plugdev lpadmin admin sambashare
    thorsten@ubuntu:~/tmp$ groups thorsten
    thorsten : thorsten adm dialout cdrom plugdev nogroup lpadmin admin sambashare

Когда вы запускаете , он ищет ¹ данного пользователя в и (хотя это может быть LDAP, NIS или что-то еще ² ) и показывает все найденные группы.groups username/etc/passwd/etc/group

С другой стороны, когда вы запускаете groupsкоманду без каких-либо аргументов, она просто перечисляет все группы, к которым она сама принадлежит ³ - что не обязательно совпадает с тем, что указано в /etc/group. (См. Объяснение ниже.) Фактически, единственный поиск сделан /etc/groupдля перевода GID в имена групп.

Каждый процесс имеет набор учетных данных , который содержит (среди прочего) «реальный идентификатор группы» (первичный GID), «эффективный идентификатор группы» (EGID) и список идентификаторов «дополнительной группы» (вторичные GID). По умолчанию процесс наследует свои учетные данные от своего родителя; однако процессам, выполняющимся от имени пользователя root (UID 0) или имеющим CAP_SETUIDвозможность, разрешено устанавливать произвольные учетные данные.

В частности, когда вы входите в Linux (в tty, X11 или через SSH), процесс входа в систему (/ bin / login, gdm, sshd) ищет ваше имя пользователя, чтобы определить ваш UID, основной GID и вторичные GID. , На персональном компьютере это просто означает чтение соответствующих строк passwdи groupфайлов (или NIS, LDAP и т. Д.).

Затем процесс переходит Войти ⁴ на эти учетные данные перед началом сеанса, и каждый процесс запуска теперь будет иметь точно такой же UID и GIDs - система не проверяет , /etc/groupбольше ⁵ и не подберут любые изменения , сделанные.

Таким образом, /usr/bin/groupsпроцесс будет принадлежать к тем же группам, что и вы, когда вы вошли в систему , а не к той базе данных, в которой вы говорите.

Примечание. Приведенное выше объяснение также применимо практически ко всем Unix; к семейству Windows NT (за исключением того, что все идентификаторы UID и GID называются «SID», нет «основной группы», учетные данные называются «токеном процесса» и CAP_SETUIDпредставляют собой SeCreateTokenPrivilege или SeTcbPrivilege ); и, вероятно, для большинства других многопользовательских операционных систем.

¹ getpwuid () и getgrouplist () используются для поиска групп пользователей.

² В Linux glibc использует, /etc/nsswitch.confчтобы определить, где искать эту информацию.

³ groups использует getgid (), getegid () и getgroups () для получения своих учетных данных.

⁴ setuid (), setgid (), initgroups () и связанные с ними.

⁵ Исключение, конечно, различные инструменты , которые работают повышенные ( Setuid ) , такие как su, sudo, sg, newgrp, pkexec, и так далее. Это означает, что su $USERпоявится оболочка с обновленным списком групп.

groupsСам по себе дает текущее членство в группе владельца процесса. Это может отличаться от groups <username>того, изменилась ли groupdb с момента запуска процесса или изменился владелец процесса.

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

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

Запустите updatedb, посмотрите, есть ли какие-либо изменения.

То же самое в моей машине OSX, когда groupdb не изменился:

albert-hotspot:~ sami$ groups sami
staff com.apple.access_screensharing com.apple.sharepoint.group.2 everyone _appstore localaccounts _appserverusr admin _appserveradm _lpadmin _lpoperator _developer
albert-hotspot:~ sami$ groups
staff com.apple.access_screensharing com.apple.sharepoint.group.2 everyone _appstore localaccounts _appserverusr admin _appserveradm _lpadmin _lpoperator _developer
albert-hotspot:~ sami$