Права доступа NFSv4

Модель прав NFSv4

Эффективный доступ определяется уровнями:

1. Клиент допущен в /etc/exports
2. Выбран security flavor: sec=sys или Kerberos
3. Сервер определил UID/GID или Kerberos principal
4. Применён root_squash/all_squash
5. Проверены Unix mode bits
6. Проверены POSIX ACL или NFSv4 ACL
7. Проверены дополнительные ограничения приложения и локальной ФС

Параметр:

rw

разрешает операции записи через export, но не выдаёт право записи в каталог.

Например:

/srv/nfs4/projects 10.20.30.0/24(rw,...)

и:

drwxr-xr-x root root /srv/nfs4/projects

означают, что обычный пользователь всё равно не может создавать файлы.

Исходная проверка

Перейти в root:

su -

На клиенте

Показать mount:

findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /mnt/projects

nfsstat -m

Проверить пользователя:

id administrator

Проверить каталог:

stat /mnt/projects

Проверить путь:

namei -l /mnt/projects

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

su - administrator -c 'touch /mnt/projects/.nfs-rights-test'

На сервере

Показать export:

exportfs -v

Проверить физический каталог:

namei -l /srv/nfs4/projects

stat /srv/nfs4/projects

getfacl -p /srv/nfs4/projects

Проверить пользователя:

getent passwd administrator
getent group <ГРУППА>

Определение активной защиты

На клиенте:

nfsstat -m

Искать:

sec=sys

или:

sec=krb5
sec=krb5i
sec=krb5p

На сервере:

exportfs -v

Искать:

sec=sys

или Kerberos flavors.

Не смешивать объяснения:

sec=sys → права в основном зависят от UID/GID
Kerberos → личность подтверждается principal, но сервер всё равно сопоставляет её с локальным пользователем

Права при sec=sys

sec=sys передаёт серверу identity клиента через Unix UID/GID.

Практический вывод:

Пользователь с UID 1000 на клиенте должен соответствовать нужному пользователю с UID 1000 на сервере.

Проверить клиент:

id administrator

Проверить сервер:

id administrator

Сравнить:

uid
primary gid
supplementary groups

Пример корректного результата:

Клиент: uid=1000(administrator) gid=1000(administrator)
Сервер: uid=1000(administrator) gid=1000(administrator)

Если на сервере UID 1000 принадлежит другому пользователю, NFS видит числовой идентификатор, а не человеческую драму вокруг совпавших имён.

Ограничение sec=sys

Клиент с административным контролем может подставлять UID/GID. Поэтому sec=sys применять только:

• в доверенной сети;
• на управляемых клиентах;
• с root_squash;
• с ограничением exports по адресам;
• для данных, где такая модель риска допустима.

Согласование UID и GID

Вариант 1. Централизованный каталог

Предпочтительный вариант:

FreeIPA
LDAP
SSSD
Active Directory через SSSD

Проверить на клиенте и сервере:

getent passwd administrator
getent group project_users

Результаты UID/GID должны совпадать.

Вариант 2. Локальные учётные записи

Если централизованного каталога нет, создать одинаковые UID/GID вручную.

Сначала проверить свободные идентификаторы:

getent passwd 1500
getent group 1500

Создать группу:

groupadd -g 1500 project_users

Создать пользователя:

useradd -u 1500 -g 1500 -m projectuser

Повторить с теми же ID на клиенте и сервере.

Не изменять UID существующего пользователя без проверки владельцев всех его файлов.

Поиск файлов старого UID

Перед изменением:

find / -xdev -uid <СТАРЫЙ_UID> -ls 2>/dev/null

Для группы:

find / -xdev -gid <СТАРЫЙ_GID> -ls 2>/dev/null

root_squash

root_squash является стандартной защитой export.

Клиентский UID 0 отображается на anonymous identity сервера.

Пример:

/srv/nfs4/projects 10.20.30.0/24(rw,sync,no_subtree_check,root_squash,sec=sys)

Проверить с клиента:

touch /mnt/projects/.root-test

На сервере:

ls -ln /srv/nfs4/projects/.root-test

В зависимости от прав каталога операция:

• будет запрещена;
• либо файл будет принадлежать anonymous UID/GID.

Удалить тест:

rm -f /srv/nfs4/projects/.root-test

no_root_squash

Не использовать для обычных файловых ресурсов:

no_root_squash

Это даёт root управляемого клиента возможность действовать как root на экспортируемой ФС.

Допустимые исключения требуют отдельного обоснования, например специализированные backup/workload-сценарии с изолированным клиентом.

all_squash и анонимная учётная запись

all_squash отображает всех пользователей в одну anonymous identity.

Пример общего drop-каталога:

/srv/nfs4/drop 10.20.30.0/24(rw,sync,no_subtree_check,all_squash,anonuid=1600,anongid=1600,sec=sys)

Создать серверную identity:

groupadd -g 1600 nfsdrop

useradd -u 1600 -g 1600 -M -s /sbin/nologin nfsdrop

Назначить каталог:

chown nfsdrop:nfsdrop /srv/nfs4/drop
chmod 0770 /srv/nfs4/drop

Проверить export:

exportfs -rav

Когда применять

• общий технический каталог;
• все файлы должны принадлежать одной service account;
• персональная идентификация пользователей не требуется;
• права контролируются на уровне export и приложения.

Когда не применять

• персональные домашние каталоги;
• аудит действий пользователей;
• shared development;
• данные, где нужен реальный владелец.

Права Unix-каталога на сервере

Доступ одной группы

Создать группу:

groupadd project_users

Добавить пользователя:

usermod -aG project_users administrator

Назначить каталог:

chown root:project_users /srv/nfs4/projects
chmod 2770 /srv/nfs4/projects

Setgid-бит:

2

обеспечивает наследование группы новыми объектами.

Проверить:

stat -c '%A %U:%G %n' /srv/nfs4/projects

Ожидается:

drwxrws--- root:project_users

Пользователь должен заново войти в сессию для получения новой supplementary group.

Проверить:

id administrator

Read-only на уровне каталога

chmod 0750 /srv/nfs4/projects

При владельце root:project_users группа получает только чтение и переход.

Но правильнее также установить ro в export, если запись не нужна:

/srv/nfs4/projects 10.20.30.0/24(ro,sync,no_subtree_check,root_squash,sec=sys)

POSIX ACL на сервере

Проверить поддержку:

getfacl -p /srv/nfs4/projects

Выдать пользователю права:

setfacl -m u:administrator:rwx /srv/nfs4/projects

Выдать группе:

setfacl -m g:project_editors:rwx /srv/nfs4/projects

Default ACL для новых объектов:

setfacl -d -m g:project_editors:rwx /srv/nfs4/projects

setfacl -d -m o::--- /srv/nfs4/projects

Проверить:

getfacl -p /srv/nfs4/projects

Маска ACL

Если ACL содержит:

mask::r-x

то запись группы будет запрещена даже при:

group:project_editors:rwx

Исправить маску:

setfacl -m m::rwx /srv/nfs4/projects

NFSv4 ID mapping

NFSv4 может представлять владельца как:

user@domain

Проверить эффективный NFSv4 domain:

nfsidmap -d

На клиенте и сервере значение должно совпадать.

Проверить конфигурацию:

grep -vE '^[[:space:]]*(#|$)' /etc/idmapd.conf

Типовой фрагмент:

[General]
Domain = example.local

Сохранить:

cp -a /etc/idmapd.conf /etc/idmapd.conf.before-rights

После изменения очистить кеш:

nfsidmap -c

Переподключить ресурс:

umount /mnt/projects
mount /mnt/projects

На новых Linux-клиентах при sec=sys часто используются числовые UID/GID, а idmapper включается при необходимости. Поэтому совпадение UID/GID всё равно остаётся обязательной практической проверкой.

Появление nobody или nogroup

Признак:

ls -ln /mnt/projects

показывает известный UID, но:

ls -l /mnt/projects

показывает:

nobody
nogroup

Проверить:

nfsidmap -d

nfsidmap -l

getent passwd <UID>
getent group <GID>

grep -vE '^[[:space:]]*(#|$)' /etc/idmapd.conf

Очистить кеш после исправления:

nfsidmap -c

Проверить журнал:

journalctl -k -b --no-pager | grep -Ei 'nfs|idmap'

Основные причины:

• пользователь отсутствует локально/в каталоге;
• разные NFSv4 domains;
• не работает SSSD/LDAP;
• закеширован отрицательный результат;
• сервер возвращает identity, которую клиент не умеет разрешить.

NFSv4 ACL

Некоторые серверные файловые системы и NFS-реализации предоставляют NFSv4 ACL.

Проверить инструменты:

command -v nfs4_getfacl
command -v nfs4_setfacl

Показать ACL:

nfs4_getfacl /mnt/projects/<FILE>

Сохранить перед изменением:

nfs4_getfacl /mnt/projects/<FILE> \
  > /root/nfs4-acl-before.txt

Редактировать интерактивно:

nfs4_editfacl /mnt/projects/<FILE>

Не смешивать бездумно:

POSIX ACL
NFSv4 ACL
Windows-style allow/deny ACE

Поддержка и отображение зависят от серверной ФС и NFS-сервера. Если nfs4_getfacl не поддерживается, управлять правами через Unix mode/POSIX ACL на сервере.

Права при Kerberos

Kerberos flavors:

sec=krb5   — аутентификация
sec=krb5i  — аутентификация и целостность
sec=krb5p  — аутентификация, целостность и шифрование

Проверить mount:

nfsstat -m

Проверить ticket пользователя:

su - administrator -c 'klist -ef'

Проверить identity на сервере:

getent passwd administrator

Даже при Kerberos серверу нужен способ сопоставить principal с локальной учётной записью и её группами.

Пример export:

/srv/nfs4/projects 10.20.30.0/24(rw,sync,no_subtree_check,root_squash,sec=krb5p)

Пример mount:

mount -t nfs \
  -o nfsvers=4.2,hard,sec=krb5p \
  nfs01.example.local:/projects \
  /mnt/projects

Проверить доступ именно от имени пользователя с ticket:

su - administrator -c \
  'touch /mnt/projects/.krb5-rights-test'

Несколько пользователей и служб

Пользовательский доступ

Для sec=sys:

• UID/GID одинаковы на клиенте и сервере;
• группы одинаковы;
• серверный каталог имеет подходящие mode/ACL.

Служба

Определить service account:

id <SERVICE_USER>

Проверить от её имени:

su -s /bin/sh -c \
  'touch /mnt/projects/.service-test' \
  <SERVICE_USER>

Удалить:

rm -f /mnt/projects/.service-test

Не запускать приложение от root ради обхода прав

Если root клиента не может писать из-за root_squash, это штатное поведение.

Правильное решение:

• service account;
• подходящий UID/GID;
• группа;
• ACL;
• Kerberos principal.

Неправильное:

no_root_squash

только потому, что приложение лениво настроено.

Самодостаточные сценарии

Сценарий 1. Пользователь видит файлы, но не пишет

На клиенте:

id administrator
nfsstat -m
su - administrator -c \
  'touch /mnt/projects/.write-test'

На сервере:

id administrator
exportfs -v
namei -l /srv/nfs4/projects
getfacl -p /srv/nfs4/projects

Исправить группу:

usermod -aG project_users administrator
chown root:project_users /srv/nfs4/projects
chmod 2770 /srv/nfs4/projects

Пользователю заново войти в систему.

Повторить тест.

Сценарий 2. Root клиента получает Permission denied

Проверить export:

exportfs -v

Если включён:

root_squash

это ожидаемо.

Создать service account и запускать операцию от неё:

su -s /bin/sh -c \
  'touch /mnt/projects/.service-test' \
  <SERVICE_USER>

Не отключать root_squash без отдельного решения.

Сценарий 3. Файлы отображаются как nobody

Клиент:

nfsidmap -d
getent passwd <UID>

Сервер:

nfsidmap -d
getent passwd <UID>

Исправить /etc/idmapd.conf или источник identities.

Очистить кеш на клиенте и сервере:

nfsidmap -c

Переподключить mount.

Сценарий 4. Все файлы должны принадлежать одной службе

Сервер:

groupadd -g 1600 nfsapp
useradd -u 1600 -g 1600 -M -s /sbin/nologin nfsapp
chown nfsapp:nfsapp /srv/nfs4/app
chmod 0770 /srv/nfs4/app

Export:

/srv/nfs4/app 10.20.30.0/24(rw,sync,no_subtree_check,all_squash,anonuid=1600,anongid=1600,sec=sys)

Применить:

exportfs -rav

Клиент:

touch /mnt/app/.ownership-test

Сервер:

stat /srv/nfs4/app/.ownership-test

Ожидаемый владелец:

nfsapp:nfsapp

Проверка результата

Клиент

nfsstat -m

id administrator

su - administrator -c \
  'touch /mnt/projects/.rights-final-test'

su - administrator -c \
  'stat /mnt/projects/.rights-final-test'

su - administrator -c \
  'rm /mnt/projects/.rights-final-test'

Сервер

exportfs -v

getfacl -p /srv/nfs4/projects

journalctl -k -b --no-pager | grep -Ei 'nfs|idmap|permission'

Типовые ошибки

Откат

Сохранить до изменений:

getfacl -Rp /srv/nfs4/projects \
  > /root/projects-acl-before.txt

Сохранить ownership/mode:

stat -c '%u %g %a %n' /srv/nfs4/projects \
  > /root/projects-mode-before.txt

Сохранить exports:

cp -a /etc/exports /etc/exports.before-rights

Вернуть ACL:

setfacl --restore=/root/projects-acl-before.txt

Вернуть exports:

cp -a /etc/exports.before-rights /etc/exports
exportfs -ra

Вернуть idmap config:

cp -a /etc/idmapd.conf.before-rights /etc/idmapd.conf
nfsidmap -c

Удалять созданных пользователей и группы только после проверки, что им не принадлежат другие файлы:

find / -xdev -uid <UID> -ls 2>/dev/null
find / -xdev -gid <GID> -ls 2>/dev/null

Источники

• exports(5): root_squash, all_squash, anonuid, anongid, sec
• nfs(5): security flavors NFSv4
• nfsidmap(8): NFSv4 identity mapping
• rpc.idmapd(8)
• nfs4_acl(5)
• nfs4_getfacl(1)
• nfs4_setfacl(1)
• ALT Linux 10.4: NFS