Как разрешения для 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 to phil:phil он не может прочитать файл. Процесс начался следующим образом:

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

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

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

Так что на самом деле вопрос:

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

3 Solutions collect form web for “Как разрешения для Linux работают, когда процесс выполняется как определенная группа?”

Процесс выполняется с помощью uid ang a gid. У обоих есть права, назначенные им. Вы можете вызвать chroot с пользовательским интерфейсом пользователя и группы, где фактически пользователь не находится в этой группе. Затем процесс будет выполняться с пользователями 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) 

Hm, но пользователь не находится в этой группе ( 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 как свой контекст. С «take» я подразумеваю, что это делает ядро, иначе это будет проблема безопасности.

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

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

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

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

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

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

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

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

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

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

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

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

  • Как добиться эффекта chroot в пользовательском пространстве в Linux (без root)?
  • Как найти текущий путь chroot jail в Linux <2.6.26
  • Ограничить пользователей SFTP разными каталогами
  • ошибка файла pid при запуске stunnel
  • Как chroot в загрузочную среду?
  • debootstrap не работает в кали и мяте
  • Реальный chroot на системной машине
  • Как работает chrooting в ОС?
  • Имеет ли смысл использовать SELinux внутри тюрьмы chroot?
  • Как rsync chroot без нарушения символических ссылок?
  • Разрешение запрещено в скриптовой тюрьме chroot
  • Linux и Unix - лучшая ОС в мире.