Как работают разрешения Linux, когда процесс выполняется как определенная группа?

Это то, что я не смог найти много информации, поэтому любая помощь будет оценена.

Мое понимание таково. Возьмите следующий файл:

-rw-r-----  1 root        adm   69524 May 21 17:31 debug.1

Пользователь philне может получить доступ к этому файлу:

phil@server:/var/log$ head -n 1 debug.1
cat: debug.1: Permission denied

Если philон добавлен в admгруппу, он может:

root@server:~# adduser phil adm
Adding user `phil' to group `adm' ...
Adding user phil to group adm
Done.
phil@server:/var/log$ head -n 1 debug.1
May 21 11:23:15 server kernel: [    0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014

Однако, если процесс запускается, в то время как явное задание user:groupдля phil:philнего не может прочитать файл. Процесс начался так:

nice -n 19 chroot --userspec phil:phil / sh -c "process"

Если процесс запущен как phil:adm, он может прочитать файл:

nice -n 19 chroot --userspec phil:adm / sh -c "process"

Таким образом, вопрос на самом деле:

Что особенного в запуске процесса с определенной комбинацией пользователя / группы, которая не позволяет процессу получить доступ к файлам, принадлежащим дополнительным группам этого пользователя, и есть ли способ обойти это?

Процесс запускается с помощью UID и GID. Оба имеют назначенные им разрешения. Вы можете вызвать chroot с userpec пользователя и группы, где на самом деле пользователь не входит в эту группу. Затем процесс будет выполняться с использованием пользовательских uid и заданных gid групп.

Смотрите пример. У меня есть пользователь user, и он входит в группу student:

root@host:~$ id user
uid=10298(user) gid=20002(student) groups=20002(student)

У меня есть файл следующим образом:

root@host:~$ ls -l file
-rw-r----- 1 root root 9 Mai 29 13:39 file

Он не может прочитать это:

user@host:~$ cat file
cat: file: Permission denied 

Теперь я могу выполнить catпроцесс в контексте пользователя userИ группы root. Теперь процесс cat имеет необходимые разрешения:

root@host:~$ chroot --userspec user:root / sh -c "cat file"
file contents

Интересно посмотреть, что idговорит:

root@host:~$ chroot --userspec user:root / sh -c "id"
uid=10298(user) gid=0(root) groups=20002(student),0(root)

Хм, но пользователь userне входит в эту группу ( root). Где idвзять информацию? Если idвызывается без аргумента, используются системные вызовы getuid(), getgid()и getgroups(). Таким образом, сам контекст процесса idпечатается. Этот контекст мы изменили с --userspec.

При вызове с аргументом idпросто определяет групповые назначения пользователя:

root@host:~$ chroot --userspec user:root / sh -c "id user"
uid=10298(user) gid=20002(student) groups=20002(student)

На ваш вопрос:

Что особенного в запуске процесса с определенной комбинацией пользователя / группы, которая не позволяет процессу получить доступ к файлам, принадлежащим дополнительным группам этого пользователя, и есть ли способ обойти это?

Вы можете установить контекст процесса безопасности, необходимый для решения любой задачи, которую должен выполнить процесс. У каждого процесса есть набор uid и gid, под которым он работает. Обычно процесс «принимает» в качестве контекста вызывающих пользователей uid и gid. С «берет» я означает, что ядро ​​делает, иначе это было бы проблемой безопасности.

Таким образом, на самом деле это не пользователь, у которого нет прав на чтение файла, это права доступа процесса ( cat). Но процесс выполняется с помощью uid / gid вызывающего пользователя.

Таким образом, вам не нужно входить в определенную группу, чтобы процесс запускался с вашим uid и gid этой группы.

Использование --userspecопции on chrootуказывает пользователя и одну группу для использования при запуске chroot. Для определения дополнительных групп вам также необходимо использовать эту --groupsопцию.

По умолчанию процессы наследуют основную и дополнительную группы пользователя, который их запускает, но при использовании --userspecвы chmodуказываете переопределить это, используя одну указанную группу.

Подробная документация по разрешениям в Linux доступна на credentials(7)странице руководства .

Когда вы входите в Linux, процесс входа в систему - после проверки того, что вы можете войти в систему как phil - получает идентификатор пользователя phil и группы, к которым он принадлежит, устанавливая их как процесс, который затем запускается как ваша оболочка. UID, GID и дополнительные группы являются свойством процесса.

Любая более поздняя программа, запущенная после этого, является потомком этой оболочки и просто получает копию этих учетных данных. * Это объясняет, почему изменение прав пользователя не влияет на запущенные процессы. Однако изменения будут приняты при следующем входе в систему.

* Исключение составляют программы, в которых установлены биты setuid или setgid, которые будут иметь другой эффективный идентификатор пользователя . Это используется, например, в su (1), поэтому он может работать с rootпривилегиями, даже если выполняется phil.

После того, как вы добавите philв admгруппу, он может запустить su philи su, работая с правами root, убедиться, что он действительно предоставил пароль Фила, а затем посадить его в оболочку с uid, gid и дополнительными группами, к которым принадлежит phil. И поскольку это делается после добавления пользователя в группу, эта оболочка уже будет в admгруппе.

Я не считаю chroot (1) наиболее подходящей программой для запуска под другим пользователем , но она, безусловно, выполняет свою работу. Параметр --userspec phil:philзаставляет его работать с uid of philи gid of phil. Дополнительные группы не установлены (для этого вы бы предоставили --groups). Таким образом, процесс детей не в admгруппе.

Более нормальный способ запустить ваш процесс, как Фил su phil -c "process". При suзагрузке групп uid, gid и дополнительных групп из информации базы данных пользователей processбудут иметь те же учетные данные, что и пользователь в настоящее время.

May Это может быть login (1) , sshd, su, gdb или другие программы. Кроме того, это, вероятно, управляется через модули pam.