> Иерархические acl'и актуальны в наши дни только сетевым и кластерным fs.Ну не только в наши дни... оно и раньше было актуально в первую очередь для этой задачи. В локальной даже n-пользовательской системой в которой нет гуманитарного понятия "сетевой вход в систему" использование сложной иерархии ACL ничего не даёт, разве что кроме некоторого замедления доступа к диску.
И наоборот, если у вас есть 2 формы ACL, одна какая-то упрощенная на ФС, а другая отдельная для реализации сетевого функционала, то этот маппинг одного в другое - еще большее расточительство к ресурсам.
Такие ФС, как ZFS, NTFS или вот даже HFS+ подходят лучше для задач сетвевых и кластерных FS, чем любая обычная ext4, XFS и иже с ними. Это вопрос подбора ФС под свою задачу.
> повторяю: проблема в том, что локальный пользователь отличный от меня, любимого - в сегодняшнем мире как раз - нонсенс, компьютеры - персональные.
В этом случае наличие ФС со сложными ACL вам не нужна. Если вы используете NTFS то вам по-умолчанию предлагается использовать ряд элементарных упрощенных преднастроенных правил ACL, который драйвер дробит быстро и решительно. И вот тут и начинается разница в Linux "мама" - это чертовы 9 бит, а любой ACL - сбоку. И вместо того чтобы сделать отображение/представления ACL в 9 бит для обратной совместимости и прописать эти же правила, как упрощенные ACL (как в Macos) тут такого нагородили... и еще и обороняют своего уродца-инвалида, когда, на минуточку, в Solaris, MacOS все сделано вполне себе открытыми сановскими технологиями минимальным Sun RPC (OPC) / NFSv4 ACL, и то RPC там нужен-то только для узкого круга задач.
Я со своей стороны скажу. Если у вас есть гибкая файловая система с нормальными ACL И (обязательно И) у вас есть ядро/драйвер которое адекватно работает с этими ACL, подразделяя их на разные представления, чтобы на локальных задачах не задействовался сетевой функционал, на бескерберосных средах не действовали внешние SID, на без claim-овых средах не работали условные ACL с атрибутами - У вас (пользователя/администратора) всё будет хорошо и с функционалом и с производительностью.
Вариант из серии: мы выкатим огрызок, ой нам не хватаем сбоку прикрутим нестандартизированного уродца которого надо мапить в сетевые ACL через боль и потом будем с усёром доказывать что это круто и сделать нормальную систему не надо - это хрестоматийное поведение линуксоидов, которое я вижу повсеместно, аж до обсуждений истеричек lklm. Не думайте, что это opennet чем-то плохой, нет. Бараны повсюду, гляньте в комменты: https://lwn.net/Articles/788335/
> Неперсональные у нас сервера, но тем _локальная_ fs с нагромождениями acl'ей как раз не требуется, вон у моего кластера вообще 600 на все файлы, потому что права доступа он на другом физическом юните хранит (правда, обратите внимание - и с кластерами в линуксе опа полная в этом плане, там даже пресловутые девять бит не везде правильно работают, чаще первые три только - то есть даже и от честных людей замков толком нет).
Если вы под кластером имеете в виду традиционный кластер, когда у вас есть, HA/LB, ноды, хартбит, менеджмент ресурсов и кластерное хранилище и обсуждаете права именно на пресловутом "кластерном хранилище" в традиционном смысле, то тогда я могу понять почему вы там что-то мапили по sid-ам, потому что адекватного иного способа вроде бы нет в unix. А реальные ACL приложения у вас там хранит, какая-то база, небось. Тогда все понятно.
В мире MS просто все то же самое только лишь с точностью до SID, которые традиционно нельзя брать откуда попало. Там просто создается керберос-учетка для делегирования внешних пользователей на ноды. Использовать этот подход на *nix ничто не запрещает. Для таких кластеров NTFS и SMB имеют специальный упрощенный профиль для работы с ACL и метаданными (писал выше про такие приемы). И! Если вы создаете такой кластер в котором у вас почему-то нельзя использовать Kerberos, то вы используете вариант с взаимным доверием SSL-сертификатам всех нод этого кластера. И чисто технически у вас нет возможности организовать там вменяемую аутентификацию пользователя (нет кербероса и ничего для олицетворения), если делаете кластеризованный файловый сервер. Безопасность будет снижена, поэтому шарить файло оттуда людям не рекомендуют, только в доверенные приложения. То есть методика достижения цели другая, но архитектура будет ну практически 101.
Вам только нужно проставить им правильные DNS-суффиксы. Задача специфична для Windows, который по традиции имеет треклятую службу IBM NetBT по умолчанию, вместо нормальных имен хостов. В итоге вы получите кластер в недоменной или мультидоменной среде. НО! Это нетипичная задача. Традиционный кластер, предполагается использовать в одной группе префиксов сетей и в большинстве случаев эти префиксы находятся под управлением одного керберос-реалма. Гибридные-облачные среды, когда одна нода где-то там далеко в облаках федерируются иначе. И да, я тут пишу про взаимное доверие по SSL между нодами и DNS, как о нормальном решении, специально забывая о косорылых:
+ LocalAccountTokenFilterPolicy=1,
+ NTLM-Only Fresh Credentials Delegation
+ CredSSP Trusted Hosts
которые точно также дадут локальным админам (но не пользователям) возможность рулить всем-всем-всем, надо только понасоздавать пользователей с одними и теми же именами :) ничего не напоминает?
Но, в этой ситуации, у вас полный NTLM и IBM NetBIOS примечательно, что это технологии той же эпохи, что и unix sid и девятибитные "ACL". И несмотря на это, у NTLMv2 безопасность будет выше, чем у вашего решения.
Однако, это такая косорылая жесть, что лучше этим не пользоваться. Я не хочу вдаваться в детали реализации на таких технологиях, чтобы не приведи Кришна, кто-то не додумался, прочитав, воспользоваться этим "решением". Ирония в том, что в мире Linux такие подходы по безопасности - это норма. Что только не придумают, лишь бы керберосом не пользоваться.
А про именно Linux в вопросах традиционной кластеризации в отличии от других unix ОС я ничего сказать не могу. Никогда ему не доверял такие задачи. Особенно инфраструктурные кластеризации, наслушавшись от знакомых и насмотревшись на их боль про падающие и разваливающиеся CEPH-и. Тот случай, когда NTFS + SMB + S2D надежнее.
