Это то, что я не смог найти много информации, поэтому любая помощь будет оценена.
Мое понимание таково. Возьмите следующий файл:
-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
:У меня есть файл следующим образом:
Он не может прочитать это:
Теперь я могу выполнить
cat
процесс в контексте пользователяuser
И группыroot
. Теперь процесс cat имеет необходимые разрешения:Интересно посмотреть, что
id
говорит:Хм, но пользователь
user
не входит в эту группу (root
). Гдеid
взять информацию? Еслиid
вызывается без аргумента, используются системные вызовыgetuid()
,getgid()
иgetgroups()
. Таким образом, сам контекст процессаid
печатается. Этот контекст мы изменили с--userspec
.При вызове с аргументом
id
просто определяет групповые назначения пользователя:На ваш вопрос:
Вы можете установить контекст процесса безопасности, необходимый для решения любой задачи, которую должен выполнить процесс. У каждого процесса есть набор uid и gid, под которым он работает. Обычно процесс «принимает» в качестве контекста вызывающих пользователей uid и gid. С «берет» я означает, что ядро делает, иначе это было бы проблемой безопасности.
Таким образом, на самом деле это не пользователь, у которого нет прав на чтение файла, это права доступа процесса (
cat
). Но процесс выполняется с помощью uid / gid вызывающего пользователя.Таким образом, вам не нужно входить в определенную группу, чтобы процесс запускался с вашим uid и gid этой группы.
источник
EUID
частью которых является, путем вызоваinitgroups(3)
. Однакоinitgroups(3)
это относительно дорогая операция, поскольку для нее необходимо перечислить все группы. По этой причине процессы вызывают только в томinitgroups(3)
случае, если у них есть конкретная причина для этого.Использование
--userspec
опции onchroot
указывает пользователя и одну группу для использования при запуске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 ofphil
и gid ofphil
. Дополнительные группы не установлены (для этого вы бы предоставили--groups
). Таким образом, процесс детей не вadm
группе.Более нормальный способ запустить ваш процесс, как Фил
su phil -c "process"
. Приsu
загрузке групп uid, gid и дополнительных групп из информации базы данных пользователейprocess
будут иметь те же учетные данные, что и пользователь в настоящее время.May Это может быть login (1) , sshd, su, gdb или другие программы. Кроме того, это, вероятно, управляется через модули pam.
источник