Я предоставляю сервер NFS как часть совместного проекта с другой группой, производящей клиентское программное обеспечение, над которым я не контролирую. Их программное обеспечение предоставляет своим пользователям управление файлами через веб-интерфейс и службу, а в качестве бэкэнда хранилища оно использует базовую файловую систему, для которой мы хотим начать использовать NFS.
До сих пор они разрабатывали локальную файловую систему, и теперь, когда они пробуют сервер NFS, они обнаруживают, что не могут назначить CAP_CHOWN возможность их программы. Я не нашел способа включить это, но я также не нашел документированной причины, по которой это невозможно.
Очевидная альтернатива - запустить chown операции как root, так или иначе, как экспорт файловой системы на свою машину с no_root_squash не вызывает беспокойства в данной ситуации. Однако они (по понятным причинам) не хотят запускать свою веб-службу с правами root, поэтому я полагаю, что одним из них будет создание SUID. chown двоичный файл на клиенте и вызывается из веб-службы.
Другой альтернативой может быть сопоставление пользователя их приложения с пользователем root на сервере NFS, как если бы они работали на клиенте с правами root. Это кажется странным с точки зрения безопасности, но мне кажется, что это небольшая чистая выгода. Но на стороне сервера это немного неудобно с точки зрения ремонтопригодности. Кроме того, я не знаю, возможно ли это; Я только прочитал idmapd.conf(5) man, и я сомневаюсь, что изначально рассматривался этот вариант использования. Это может быть явно запрещено.
Я продолжаю смотреть на это, и если я найду что-нибудь, я обновлю это, но если у кого-то есть предложения или кто-нибудь может меня просветить capabilities(7) работаю с nfsd(8), Буду признателен.
Обновление №1: Увидев, есть ли в списках ACL NFSv4 какие-то гранулярные ACE (записи управления доступом), которые необходимо ослабить, я обнаружил, что есть o разрешение, которое разрешает владение. Это многообещающе, но я все еще пытаюсь заставить это работать: по крайней мере, в моей системе (Ubuntu 16.04) это принято синтаксически, но не применяется и не имеет никакого эффекта:
[test-nfs] nfs4_setfacl -a A::OWNER@:o testfile
[test-nfs] nfs4_getfacl testfile
A::OWNER@:tTcCy
A::GROUP@:tcy
A::EVERYONE@:tcy
[test-nfs] nfs4_setfacl -a A::OWNER@:r testfile
[test-nfs] nfs4_getfacl testfile
A::OWNER@:rtTcCy
A::GROUP@:tcy
A::EVERYONE@:tcy
Я испортил некоторые параметры монтирования / экспорта как на клиенте, так и на сервере, но пока это не работает.
Обновление №2: В соответствии с эта тема, нет возможности CAP_CHOWN чтобы передаваться от клиента к серверу, и поэтому не влияет на монтирование NFS.
Я пытаюсь определить, должно ли работать разрешение на владение NFSv4 ACL и что мне там не хватает.
Обновление № 3: Согласно тому же потоку выше, разрешение на владение в списках ACL NFSv4 не может быть должным образом представлено с помощью списков ACL POSIX, и поэтому требуется более широкий набор ACL. Был работа над этим, который, по-видимому, остановился.
Не похоже, что я могу делать то, что хочу, с программным обеспечением как есть, и требуется вышеупомянутый кладж SUID или что-то в этом роде, чтобы операция смены владельца выполнялась от имени пользователя root.
В imapd.conf(5) подход, который мне не понравился, но все равно попробовал, невозможен, потому что статическое сопоставление идентификаторов применяется только в контексте безопасности Kerberos, который я не использую.
Итак, я не думаю, что на этот вопрос почти нет ответа.