Как обстоят дела с «процессом, работающим с дополнительными привилегиями, на который может опираться»?

С https://unix.stackexchange.com/a/18290/674

Ядро зрения

Концептуально существует три набора групп, членом которых является процесс. Каждый набор является подмножеством следующего.

  1. Единственная группа, которая является группой процесса по умолчанию, к которой будут принадлежать файлы, созданные этим процессом.
  2. Набор групп, которые проверяются, когда группе требуется разрешение на открытие файла .
  3. Набор групп, на которые может опираться процесс с дополнительными привилегиями.

По историческим причинам эти наборы соответственно:

  1. эффективный идентификатор группы (egid);
  2. эффективный идентификатор группы плюс дополнительные идентификаторы группы ;
  3. все вышеперечисленное плюс реальный идентификатор группы и сохраненный набор-идентификатор группы .

Вопросы:

  1. Как обстоят дела с «процессом, запущенным с дополнительными привилегиями, на который может опираться» в пункте 3?

    Отличается ли этот случай от случая «когда группе требуется разрешение на открытие файла» в пункте 2?

  2. Включают ли «дополнительные идентификаторы группы» основной идентификатор группы в целом и в пункте 2 соответственно?

    Под «в общем» я подразумеваю, что я заметил, что выходные данные id include в себя как первичные, так и дополнительные группы, следующие за groups= , тогда как https://unix.stackexchange.com/a/18203/674 говорит, что «каждый пользователь может принадлежать к числу дополнительных групп – и они перечислены в конце вывода id . ” Поэтому мне интересно, если основная группа также является дополнительной группой?

Благодарю.

  1. В частности, в Linux в настоящее время «процесс, запущенный с процессом с дополнительными привилегиями, может использовать» – это процесс, который «имеет возможность CAP_SETGID в своем пространстве имен пользователя» .

    Обратите внимание, что введение трех пунктов гласит, что «каждый набор является подмножеством следующего», поэтому да, набор, описанный в пункте 3, концептуально отличается от набора, описанного в пункте 2.

  2. id печатает эффективную группу, а не основную группу; Вы можете изменить свою эффективную группу, используя newgrp . Основная группа является реальной / эффективной группой по умолчанию. В Linux на getgroups руководства getgroups упоминается, что «не указано, включен ли эффективный идентификатор группы вызывающего процесса в возвращаемый список», поэтому дополнительные группы не обязательно include основную группу.

Тем не менее, учитывая Linux, стоит почитать справочную страницу по учетным данным .

Учитывая количество различных концепций, я нахожу их легче изучать на практических примерах.

Программы, подобные NFS-серверу пользователя, действуют от имени определенного пользователя, подключенного по сети. Они временно меняют действующие идентификаторы пользователей и групп, например, при открытии файла от имени конкретного пользователя. Они могут переключаться обратно, потому что у них все еще есть привилегированный UID и GID в их «сохраненном наборе» или «реальном» UID и GID.

Недавно я узнал, что fusermount – это еще один пример программы, которая делает это. Это должен быть root-uid для того, чтобы он мог монтировать файловые системы, но он хочет выполнять проверку прав как первоначальный пользователь, например, при чтении файлов конфигурации и достижении каталога, который передается как точка монтирования. По крайней мере, он должен изменить свой UID следующим образом. Если бы эта программа была также set-gid, то ей также пришлось бы изменить свой GID. fusermount не нужно устанавливать как set-gid, но код все равно меняет свой эффективный GID. Это не займет много кода, и, по крайней мере, я надеюсь, что это не вызовет никаких проблем :-).

Страница man для setfsgid() упоминает этот пример, когда говорит

Явные вызовы setfsuid () и setfsgid () обычно используются только такими программами, как сервер NFS Linux, которым необходимо изменить то, какой идентификатор пользователя и группы используется для доступа к файлу, без соответствующего изменения реальных и эффективных идентификаторов пользователя и группы.

[…]

Атрибут идентификатора пользователя файловой системы был добавлен для того, чтобы процесс мог изменить свой идентификатор пользователя в целях проверки разрешений на доступ к файлам, не становясь при этом уязвимым для получения нежелательных сигналов. Начиная с Linux 2.0, обработка разрешений сигналов отличается (см. Kill (2)), в результате чего изменение процесса может изменить его эффективный идентификатор пользователя, не будучи уязвимым для приема сигналов от нежелательных процессов. Таким образом, setfsuid () в настоящее время не требуется, и его следует избегать в новых приложениях (аналогично для setfsgid (2)).

т.е. текущие версии этих программ будут временно менять свои эффективные UID и GID, используя setresuid () и setresgid ().