У меня есть вопрос / путаница относительно принудительного использования унаследованных разрешений в Linux (а именно CentOS 6)
Настройка:
1 x файловый сервер CentOS
2 клиента CentOS NFS
Много x Windows Samba клиентов
Файловый ресурс / srv / share используется совместно с локальными разрешениями Samba и NFS: h
drwxrwx---. 2 root sharegroup 4.0K Oct 22 14:41 share
Все UID / GID объединены через Active Directory, основная группа для всех пользователей - sharegroup.
Клиент NFS смонтирован в fstab как:
tst-lnx03:/srv/share /mnt/share nfs defaults 0 0
Окно Windows через путь UNC:
\\tst-lnx03\share
Что бы я хотел:
Все, что написано / создано в папке / srv / share, независимо от того, пришло ли оно через NFS или Samba, то есть корневая группа 770.
Что я пробовал:
Я пробовал использовать ACL:
setfacl -m d:u:root:rwx,d:g:"sharegroup":rwx,d:other:--- share
В результате:
ls -lah
-rwxrwx---+ 1 testuser11 sharegroup 0 Oct 22 14:25 tu12-smb-win
-rw-rw----+ 1 testuser2 sharegroup 0 Oct 22 14:23 tu2-local-local
-rw-r-----+ 1 testuser4 sharegroup 0 Oct 22 14:24 tu4-NFS-lnx04
Я пробовал использовать липкие биты:
chmod 2770 share
В результате:
ls -lah
-rwxr--r-- 1 testuser11 k8 sharegroup 0 Oct 22 14:38 tu12-smb-win
-rw-r--r-- 1 testuser2 k8 sharegroup 0 Oct 22 14:38 tu2-local-local
-rw-r--r-- 1 testuser4 k8 sharegroup 0 Oct 22 14:38 tu4-NFS-lnx04
Спутанность сознания
Похоже, что setfacl является победителем, но меня немного смущает вывод, почему версия с липким битом добавляет случайное другое чтение и удаляет группу списания?
Я думаю, что могу отнести созданный NFS файл к другому из-за umask по умолчанию 0022, но не других изменений. Я ожидал, что созданные окна и локально созданные файлы будут соответствовать разрешениям.
Может ли кто-нибудь объяснить, что происходит в каждом случае? Я немного озадачен. Если тебе нужно от меня что-нибудь еще, кричи, и я поставлю это.
Так ты сделал
setfacl -m d:u:root:rwx,d:g:"sharegroup":rwx,d:other:--- share
Все, что вы делаете с setfacl d: (известный как «ACL по умолчанию») не влияет на владение, только на доступность. Таким образом, вы можете решить, «кому есть доступ», но не «кому принадлежит». Вы только что предоставили тестовым файлам доступ rwx для пользователя-владельца и для пользователя root; и доступ rwx для группы-владельца и для «sharegroup». Но пользователь-владелец и группа-владелец определялись точно так же, как и без setfacl.
Разрешения файлов неожиданные, потому что с файлом setfacl'd umask больше не учитывается. Каждый файл имеет свою «собственную маску», известную просто как маска (см. getfacl).
И ты сделал
chmod 2770 share
Снова неверно. 2770 не липкий, это бит setgid. Sticky было бы 1770. setgid изменил группу-владельца для новых файлов и никак не повлиял на их права доступа. В разрешениях, как обычно, учитывается umask (см. umask) и режим, предложенный приложением, создающим файл.
Я не знаю, как можно правильно реализовать то, что вам нужно, с помощью имеющихся у вас инструментов. В Linux нет «setuid для каталогов».