Доступ к папке только для групп на Overlayfs2 на NFSv4 с включенным root_squash?

Фон

Для экспорта/общего доступа NFSv4 включенная по умолчанию опция root_squash заставит NFS изменить корень клиента на анонимный идентификатор. По сути, это повысит безопасность, предотвращая миграцию владельца учетной записи root из одной системы в другую.

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

Зачем монтировать Overlayfs поверх общего ресурса NFS? Чтобы позволить менее доверенной машине притвориться, что она может писать в общую файловую систему.

Испытательная установка

Сначала установите сервер ядра NFS, соответствующий вашему дистрибутиву. Затем убедитесь, что вы экспортируете только NFSv4. (Хотя, вероятно, это не важно для этой проблемы, это хорошая мера безопасности.)

      $ sudo cat /proc/fs/nfsd/versions
-2 -3 +4 +4.1 +4.2

Если нет, посмотрите/etc/nfs.confи установитьvers3=n.

Затем создайте файловую систему Ext4 в разреженном файле и смонтируйте ее в локальной файловой системе. Это будет файловая система, лежащая в основе нашей общей папки NFS.

      $ truncate -s 512M 512BM-ext4.img
$ mkfs.ext4 512BM-ext4.img
$ sudo mkdir /mnt/ext4-file
$ sudo mount -o loop,noacl 512BM-ext4.img /mnt/ext4-file

Затем поделитесь/экспортируйте эту файловую систему по сети с помощью NFSv4 на соответствующий компьютер. В этом примере я буду использовать localhost, но это может быть любой компьютер в локальной сети. Сделайте это, отредактировав/etc/exportsчтобы иметь строку, подобную следующей.

      /mnt/ext4-file/ localhost(ro,fsid=123123)

Затем перезапустите сервер NFS на своем компьютере, служебные файлы в вашей ОС могут отличаться.

      $ sudo systemctl restart nfs-server.service nfs-mountd.service
$ sudo exportfs -v
/mnt/ext4-file  localhost(sync,wdelay,hide,no_subtree_check,fsid=123123,sec=sys,ro,secure,root_squash,no_all_squash)

Гарантировать, чтоroot_squashиroвключен.

Теперь можно смонтировать общий ресурс NFSv4 на предполагаемом клиенте.

      $ sudo mount -t nfs -o ro localhost:/mnt/ext4-file /mnt/nfs-share/
$ findmnt /mnt/nfs-share 
TARGET         SOURCE                   FSTYPE OPTIONS
/mnt/nfs-share localhost:/mnt/ext4-file nfs4   rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255

А затем монтируем overlayfs2 поверх этого общего ресурса.

      $ mkdir -p /tmp/overlay/{work,upper}
$ sudo mkdir /mnt/overlay
$ sudo mount -t overlay overlay -o lowerdir=/mnt/nfs-share/,upperdir=/tmp/overlay/upper/,workdir=/tmp/overlay/work/ /mnt/overlay/

Для нашего эксперимента мы создадим папку в файловой системе, которая может быть прочитана и записана только пользователем и прочитана группой. Я выбрал группу, принадлежащую моему пользователю.

      $ sudo mkdir /mnt/ext4-file/rovanion
$ sudo chown rovanion:rovanion /mnt/ext4-file/rovanion
$ sudo chmod 2750 /mnt/ext4-file/rovanion
$ touch /mnt/ext4-file/rovanion/hi-from-ext4
$ ls -la /mnt/nfs-share/rovanion/
totalt 8,0K
drwxr-s--- 2 rovanion rovanion 4,0K sep  6 14:14 .
drwxr-xr-x 4 root     root     4,0K sep  6 14:12 ..
-rw-rw-r-- 1 rovanion rovanion    0 sep  6 14:14 hi-from-ext4
$ touch /mnt/nfs-share/rovanion/hi-from-nfs
touch: cannot touch '/mnt/nfs-share/rovanion/hi-from-nfs': Read-only file system

Мы можем перечислить содержимое/mnt/nfs-share/rovanion, но не можем прикоснуться к файловой системе, хотя у нас есть на это разрешение, поскольку общий ресурс NFS смонтирован как доступный только для чтения. Все так, как ожидалось.

Отказ

Но вот проблема.

      $ ls -la /mnt/overlay/rovanion/
ls: cannot open directory '/mnt/overlay/rovanion/': Permission denied
$ ls -l /mnt/overlay/
total 28K
drwx------ 2 root     root      16K Sep  6 13:04 lost+found
drwxr-s--- 2 rovanion rovanion 4.0K Sep  6 14:14 rovanion
$ whoami
rovanion
$ groups
rovanion sudo

Нам запрещен доступ к списку/mnt/overlay/rovanionхотя система разрешений должна позволять нам это делать.

Я могу предположить, что происходит то, что Overlayfs осуществляет весь доступ к базовой файловой системе какrootчто с помощью корневой системы NFS сопоставляется с тем, кому не разрешен доступ к папке, посколькуnobodyне принадлежит к группеrovanionи другим не разрешено указывать папку.

Вопрос

Тогда у меня вопрос: можно ли обойти эту проблему? Чтобы разрешить пользователю доступ к папке через Overlayfs, к которой имеет доступ только выбранная группа, без отключения root_squash при экспорте/общем доступе NFS или добавленияo+rxв папку.

1 ответ

В следующем разделе документации ядра Linux по Overlayfs описывается модель разрешений.

Проверка разрешений в оверлейной файловой системе следует следующим принципам:

       1) permission check SHOULD return the same result before and after copy up
2) task creating the overlay mount MUST NOT gain additional privileges
3) non-mounting task MAY gain additional privileges through the overlay, compared to direct access on underlying lower or upper filesystems

Это достигается путем выполнения двух проверок разрешений при каждом доступе.

       a) check if current task is allowed access based on local DAC (owner, group, mode and posix acl), as well as MAC checks
b) check if mounting task would be allowed real operation on lower or upper layer based on underlying filesystem permissions, again including MAC checks

Проверка (a) обеспечивает согласованность (1), поскольку владельца, группу, режим и posix ACL копируют. С другой стороны, это может привести к игнорированию принудительных разрешений сервера (например, используемых NFS) (3).

Проверка (b) гарантирует, что ни одна задача не получит разрешения на нижележащие слои, которых нет у задачи монтирования (2). Это также означает, что можно создавать установки, в которых правило согласованности (1) не соблюдается; однако обычно задача монтирования имеет достаточные привилегии для выполнения всех операций.

Акцент мой. Я считаю, что мне удалось создать такую ​​ситуацию. Тот, где задача монтирования, выполняемая от имени пользователя root, не имеет права отображать папку, и поэтому Overlayfs запрещает пользователю доступ к папке.

Если бы мы монтировали Overlayfs как пользователь, которому разрешен доступ к файлам, то есть не root, чтобы UID не сдавливался, то, возможно, мы могли бы указать каталог и создать в нем файл?

      $ unshare --mount --map-root-user
# mount -t overlay overlay -o lowerdir=/mnt/nfs-share/,upperdir=/tmp/overlay/upper/,workdir=/tmp/overlay/work/ /mnt/overlay/
# ls -la /mnt/overlay/
totalt 28K
drwxrwxr-x 1 root   root    4,0K sep  6 14:08 .
drwxr-xr-x 7 nobody nogroup 4,0K sep  6 14:09 ..
drwx------ 2 nobody nogroup  16K sep  6 13:04 lost+found
drwxr-s--- 2 root   root    4,0K sep  6 14:14 rovanion
# touch /mnt/overlay/rovanion/hi-from-overlay

И это мы можем! А файл существует только в оверлее.

      $ ls /mnt/ext4-file/rovanion/
hi-from-ext4
$ ls /tmp/overlay/upper/rovanion/
hi-from-overlay

Хотя это решение имеет свои интересные последствия. Теперь нам необходимо включить пространства имен пользователей на наших не на 100% доверенных машинах, и мы внезапно оказываемся в пространстве, где наш UID кажется равным 0, но сопоставляется с нашим обычным идентификатором пользователя для внешнего мира. К сожалениюunshare --mountбез--map-root-userне кажется возможным.

Другие вопросы по тегам