Доступ к папке только для групп на 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
не кажется возможным.