Компы и автомобили

Постановка задачи

Возникла необходимость запилить файл-сервер на Samba и дать ряду пользователей возможность рулить правами доступа на отдельные каталоги. Система — FreeBSD 10.1 amd64, файло будет лежать на ZFS. Версия Samba — 3.6.24.

Исследование задачи показало, что стандартными правами Unix (aka «Unix mode») тут не обойтись. Надо использовать расширенный набор ACL. Например, нужно, чтобы к каталогу имели доступ более одной группы, но не все группы (т. е. разрешения для other тут не прокатит). Ну и на некоторые папки нужно давать доступ не отдельным группам, а прямо отдельным пользователям.

Общие сведения

По дефолту, как известно, в юниксах права на файлы и каталоги расставляются по схеме «ugo» — «user-group-other»). Во фре с помощью утилиты setfacl можно задавать права по двум схемам — POSIX 1.E и NFSv4, в зависимости от файловой системы. По факту же POSIX 1.E здесь сильно редуцирован — до этой самой схемы ugo. Тогда как в действительности POSIX 1.E слегка побогаче (подробности можно вкурить отсюда). Как гласит man setfacl:

The access permissions field contains up to one of each of the following: ‘r’, ‘w’, and ‘x’ to set read, write, and execute per‐ missions, respectively. Each of these may be excluded or replaced with a ‘-’ character to indicate no access.

Что в переводе означает: «Поля с разрешениями содержат букавки r, w или x для чтения, записи или выполнения соответственно».

Но это всё нам не очень интересно, так как у нас ZFS, а на ZFS ACL по умолчанию соответствуют схеме NFSv4.

Тюнинг ZFS

Поэтому прежде чем заюзать всю эту красоту с крутыми ACL на ZFS, необходимо ZFS слегка потюнить. А именно, проделать такое:

В данном случае storage0 — это имя моего ZFS-пула

zfs set aclmode=passthrough делает так, что если над папкой выполняется chmod, то при наличии у папки расширенных ACEs (access control entries) (расширенные — это те, которые помимо стандартных @owner, @group, @other), то эти ACL при этом НЕ ИЗМЕНЯЮТСЯ.

Также там есть режимы:

• discard — т. е. никаких ACL сверх стандартного unix mode сохраняться не будет;
• groupmask — новые ACL по итогу будут выставляться так, чтобы они не превышали тех, которые принадлежат @group, за исключением случая, если UID пользователя в ACL совпадает с UID владельца каталога или файла. В этом случае выставляются права не выше, чем у владельца файла. Пока даже не могу предположить, для чего такой режим может использоваться.

Если коротко, то zfs set aclinherit=passthrough необходима, для того, чтобы ACL свежесоздаваемых файлов и каталогов наследовались от каталога, в котором они создаются. Есть ещё режим passthrough-x — то же самое, что passthrough, только бит «executable» выставляется только в случае, если создающее файл приложение явным образом требует у создаваемого файла выставить бит «executable». Подробности можно вкурить тут.

Правка прав доступа из винды

В условиях задачи была заявлена необходимость дать некоему пользователю возможность управления доступом на каталоги в расшаренных папках. Причём от тонкостей командной строки пользователь бесконечно далёк, но может пользоваться виндовым диалогом прав доступа (который в свойствах папок или файлов в винде на вкладке «Безопасность» находится).

Поэтому устанавливаем владельца всех папок в шаре на определённый аккаунт, который будет админским. Допустим, это будет учётка i.ivanov. Тогда делаем так:

Первый find выставляет права full_set (это сокращение на «Полный доступ») на каталоги, а второй find — на файлы. Два find необходимы потому, что в синтаксисе команды setfacl при установке прав на каталог есть ещё модификатор «:fd:». Он означает, что права нижележащих каталогов должны наследоваться от вышестоящих. У файлов такого модификатора нет (т. е. в ACL на файлы он не предусмотрен). Если попытаться задать права на файл в формате -m u:i.ivanov:full_set:fd:allow, то setfacl выдаст ошибку.

Далее нам надо замапить группы Unix на группы в Samba. Если этого не сделать, то в диалоге «Безопасность» на винде будут видны пользователи файл-сервера (их отдаёт Самба), но не будет видно групп. Если же назначить группу руками через setfacl, то группа будет видна как «Unix Group\unixgroup»:

Но из виндового диалога добавить юниксовые группы не удастся — их там просто не видно. Чтобы они стали видны в этом диалоге, необходимы дополнительные телодвижения. Допустим, у нас есть на файл-сервере группы buhgalteria, common, engineers и bosses. Чтобы эти группы стали видны на Windows, делаем так:

И после этого в диалоге добавления прав будут присутствовать соответствующие группы. Обращаю внимание, что если имена групп NT у вас на русском, то добавлять их в маппинг надо в кодировке UTF-8.

Настройка собственно Samba

Отключаем маппинг атрибутов DOS в файлах на exec-биты и включаем хранение атрибутов DOS в виде дополнительных файлов с атрибутами. Это не обязательно, просто меня бесит, что свеже-создаваемые в SMB-шарах файлы имеют атрибут «исполняемых» при просмотре прямо в консоли сервера. Это криво и несекурно — мало ли, кто там чо зальёт.

# Disable mapping DOS bits
map hidden = no
map system = no
map archive = no

# Use extended attributes to store file modes
store dos attributes = yes

Отключаем unix extensions (они нужны для того, чтобы Самба могла работать с расширениями CIFS от HP — там можно реализовывать симлинки, хардлинки и прочее. Эти расширения могут использовать разные другие SMB-клиенты, но винда их не поддерживает. Клиенты у нас в основном на винде — поэтому unix extensions нам ни к чему. Также выставляем параметры наследования и режима обработки ACL:

• nt acl support — включает режим маппинга NT-like ACL на ACL файловой системы;
• inherit acls — включает режим наследования ACL от каталога, в котором создаются новые файлы и каталоги. Без этого параметра дополнительные ACL не будут наследоваться для новых файлов, будут наследоваться только unix mode разрешения;
• inherit owner — включает режим наследования владельца каталога, в котором создаётся файл. Без этого параметра владельцем будет становиться тот пользователь, который этот файл создаёт. В рамках нашей задачи наследование требуется, поэтому включаем;
• inherit permissions — включает наследование unix mode разрешений;
• map acl inherit — Самба будет мапить флаги «наследовать права от родительского каталога» в NT acls на файловую систему.

И в настройках шары делаем так:

На этом, собственно, всё. А теперь — дискотека! 🙂

Samba share acl windows

В предыдущих статьях был рассмотрен способ установки файлового сервера Samba в кластере и установка прав доступа на отдельные папки используя «классический» метод. Но данный метод не всегда удобен, особенно если папок на сервере много и требуется весьма разветвленная структура доступа. Весьма затруднительно вносить каждую папку, на которую требуется наложить какие-либо ограничения, в файл конфигурации сервера. Да и делегировать административные права на управление доступом гораздо проще используя другой метод. Таким методом является ACL.

Как обычно все работы будут проводиться на ОС Rosa Enterprise Linux Server 7.3 (RELS 7.3), он же CentOS 7.3, он же RedHat 7.3.

1. smb.rpn.int — файловый сервер Samba
2. otd1 — первое подразделение компании
3. otd2 — второе подразделение компании
4. unit1 — папка первого подразделения
5. unit2 — папка второго подразделения
6. share — общая папка всех подразделений.

Задача: организовать доступ к папкам таким образом:

1. Пользователи из otd1 имели полный доступ к папке unit1, но не имели доступ к папке unit2
2. Пользователи из otd2 имели полный доступ к папке unit2, но не имели доступ к папке unit1
3. Все пользователи имеют полный доступ к папке share
4. Все пользователи имеют право просматривать структуру корневой папки

В предыдущей статье рассказывалось о том, как организовать такой доступ, используя стандартные настройки Samba. Сейчас же рассмотрим более «продвинутый» метод — ACL.

Стандартные команды работы с ACL — setfacl и getfacl — подробно описаны в руководстве, поэтому здесь мы ограничимся примерами.

Для работы ACL необходимо включить поддержку этого функционала при монтировании файловой системы. Когда мы подключали кластерную файловую систему к кластеру, мы это предусмотрели:

Т.е. в параметре монтирования указываем опцию acl . Если мы не используем кластерную файловую систему, а работаем с выделенным сервером, то эта опция указывается в файле, описывающим смонтированные устройства ( /etc/fstab ). Например:

Проверить поддерживает ли раздел работу с ACL можно попыткой установить список доступа на этот раздел. Например:

Operation not supported говорит о том, что поддержка ACL не была включена и необходимо ее задействовать.

Т.к. сервер в данном примере работает в домене FreeIPA, то в первую очередь создаем несколько групп:

1. fs_users — в данную группу будут входить все пользователи, имеющие право заходить на файловый сервер, и которым будет доступен листинг корневых папок ресурса
2. fs_admins — группа пользователей, которым будут доступны все папки на сервере и которые смогут редактировать (настраивать) ACL непосредственно из файлового менеджера без доступа в консоль сервера.
3. otd1 — пользователи первого подразделения
4. otd2 — пользователи второго подразделения

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

Где FS_Share — точка монтирования диска. Далее назначаем хозяина папок и раздаем права:

Т.е. мы назначаем группу владельца файлов и папок fs_admins и разрешаем доступ с правом чтения-записи всем пользователям, принадлежащим этой группе.

Права 2770 гарантируют, что все файлы и подпапки, находящиеся в них, будут всегда создаваться с соответствующими подгруппами этих родительских папок. Немного изменим права доступа на корневую папку:

Далее настраиваем доступ к корневой общей папке и включаем ACL в конфигурации Samba:

Перезапускаем сервер Samba с новыми настройками:

В итоге на сервере появилась общая папка SHARE , в которую имеют доступ пользователи, входящие в группу fs_admins .

Остается настроить права доступа на все папки общего ресурса. Для этого переходим в консоль сервера и начинаем настройку.

Устанавливаем права просмотра содержимого корневого каталога для всех пользователей, входящих в группу fs_users (в отличии от групп Samba в группы домена FreeIPA могут входить другие группы. Т.е. в нашем случае в группу fs_admins входят группы подразделений otd1 и otd2 ):

Устанавливаем полный доступ для пользователей группы otd1 на папку и все последующие папки unit1 :

Устанавливаем полный доступ для пользователей группы otd2 на папку и все последующие папки unit2 :

Посмотреть права доступа можно выполнив следующую команду:

Т.е. мы видим, что в данную папку разрешен полный доступ группе otd2. Всем остальным доступ запрещен.

То же самое можно посмотреть для остальных папок.

В итоге мы добились поставленной цели: все пользователи могут читать структуру корневого каталога. Пользователь имеет полный доступ в папку своего подразделения. Доступ пользователю в папку чужого подразделения запрещен.

Особенности и ограничения.

Наиболее часто встречающиеся опции star :

Опция	Описание
-c	Создаёт файл архива
-n	Отключает извлечение файлов, используется в сочетании с -x для просмотра списка извлекаемых файлов.
-r	Заменяет файлы в архиве. Файлы записываются в конец архива, заменяя любые файлы с тем же путём и именем.
-t	Выводит содержимое файла архива.
-u	Обновляет файл архива. Файлы записываются в конец архива, если их ещё не было в архиве или если они новее, чем файлы с тем же именем в архиве.
-x	Извлекает файлы из архива. Если используется с ключом -U и файл в архиве старее, чем соответствующий файл в файловой системе, такой файл не извлекается.
-help	Выводит наиболее важные параметры.
-xhelp	Выводит менее важные параметры.
-/	Оставляет ведущую косую черту в имени файла при извлечении файлов из архива. По умолчанию она убирается.
-acl	При создании архива или извлечении файлов, архивирует или восстанавливает все ACL , связанные с файлами или каталогами.

Пример для архивирования утилитой star с сжатием:

Пример для разархивирования в текущий каталог:

Setting up a Share Using Windows ACLs

Namespaces

Page actions

Contents

Introduction

Extended access control lists (ACL) enable you to set permissions on shares, files, and directories using Windows ACLs and applications. Samba supports shares using extended ACLs on:

• Domain members
• Active Directory (AD) domain controllers (DC)
• NT4 primary domain controller (PDC)
• NT4 backup domain controllers (BDC)
• Standalone hosts

Preparing the Host

You need to set up Samba before you are able to create a share. Depending on what type of Samba server you require, see:

File System Support

The file system, the share will be created on, must support:

• user and system xattr name spaces.
• extended access control lists (ACL).

For further details, see File system support.

Samba Extended ACL Support

To create a share with extended access control list (ACL) support, the smbd service must have been built with ACL support enabled. A Samba host working as an Active Directory (AD) domain controller (DC), is always enabled with extended ACL support.

To verify if Samba has been built with ACL support, enter:

If no output is displayed:

• Samba was built using the —with-acl-support=no parameter.
• The Samba configure script was unable to locate the required libraries for ACL support. For details, see Package Dependencies Required to Build Samba.

Enable Extended ACL Support on a Unix domain member

Ideally you have a system that supports NFS4 ACLs. The following example is for systems like Linux, where you don’t have those kind of ACLs. To configure shares using extended access control lists (ACL) on a Unix domain member, you must enable the support in the smb.conf file. To enable extended ACL support globally, add the following settings to the [global] section of your smb.conf file:

On a Samba Active Directory (AD) domain controller (DC), extended ACL support is automatically enabled globally. You must not enable the support manually.

Alternatively, to enable extended ACL support only for a specific share, add the parameters to the share’s section.

For further details about the parameters, see the smb.conf(5) man page.

Granting the SeDiskOperatorPrivilege Privilege

Only users and groups having the SeDiskOperatorPrivilege privilege granted can configure share permissions.

Only users or groups that are known to Unix can be used. This means that if you use the winbind ‘ad’ backend on Unix domain members, you must add a uidNumber attribute to users, or a gidNumber to groups in AD.

If you use the winbind ‘ad’ backend on Unix domain members and you add a gidNumber attribute to the Domain Admins group in AD, you will break the mapping in idmap.ldb . Domain Admins is mapped as ID_TYPE_BOTH in idmap.ldb , this is to allow the group to own files in Sysvol on a Samba AD DC. It is suggested you create a new AD group ( Unix Admins for instance), give this group a gidNumber attribute and add it to the Administrators group and then, on Unix, use the group wherever you would normally use Domain Admins .

To grant the privilege to the Unix Admins group, enter:

It is recommended to grant the privilege to a group instead of individual accounts. This enables you to add and revoke the privilege by updating the group membership.

To list all users and groups having the SeDiskOperatorPrivilege privilege granted, enter:

You need to grant the SeDiskOperatorPrivilege privilege on the Samba server that holds the share.

Adding a Share

To share the /srv/samba/Demo/ directory using the Demo share name:

• As the root user, create the directory:

• To enable accounts other than the domain user Administrator to set permissions on Windows, grant Full control ( rwx ) to the user or group you granted the SeDiskOperatorPrivilege privilege. For example (if using the ‘ad’ backend):

• Otherwise for any other backend:

• Add the [Demo] share definition to your smb.conf file:

Further share-specific settings and file system permissions are set using the Windows utilities.

Do not set ANY additional share parameters, such as force user or valid users . Adding them to the share definition can prevent you from configuring or using the share.

It is recommended that you add this line to your share:

This will make Samba ignore the system ACL’s

• Reload the Samba configuration:

Setting Share Permissions and ACLs

When you configure a share with extended access control lists (ACL) support, you set the share permissions using Windows utilities instead of adding parameters to the share section in the smb.conf file.

To set permissions and ACLs on the Demo share:

• Log on to a Windows host using an account that has the SeDiskOperatorPrivilege privilege granted. e.g. SAMDOM\Administrator or SAMDOM\john where john is a member of Unix Admins .

• Click Start , enter Computer Management , and start the application.

• Select Action / Connect to another computer .

• Enter the name of the Samba host and click OK to connect the console to the host.

• Open the System Tools / Shared Folders / Shares menu entry.

• Right-click to the share and select Properties .

• Select the Share Permissions tab and check the share permissions, you need to see Everyone . For example:

If the permissions are as above, you do not need to change anything, if not, change it to just allow Everyone : Full Control, Change and Read . You should only need to make changes to the Security tab.

Samba stores the share tab permissions in the /usr/local/samba/var/locks/share_info.tdb database.

• Select the Security tab.

• Click the Edit button and set the file system ACLs on the share’s root directory. For example:

For details about using the SYSTEM account on a Samba share see The SYSTEM Account. For details where the ACLs are stored, see File System ACLs in the Back End.

• Click the Add button.

• Click Advanced button

• Click Find Now

• Select a user or group from the list, Domain Users for instance.

• Click OK

• Click OK

• Select permissions to grant, Full control for instance.

• A windows security box should open, asking if you want to continue, Click Yes

• If you check the list of Group or user names , you should find Domain Users listed

• Click OK to close the Permissions for Demo window.

• Click OK to store the updated settings.

For further details about configuring share permissions and ACLs, see the Windows documentation.

Setting ACLs on a Folder

To set file system permissions on a folder located on a share that uses extended access control lists (ACL):

• Log on to a Windows host using an account that has Full control on the folder you want to modify the file system ACLs.

• Navigate to the folder.

• Right-click to the folder and select Properties .

• Select the Security tab and click the Edit button.

• Set the permission. For example:

For details about using the SYSTEM account on a Samba share see The SYSTEM Account. For details where the ACLs are stored, see File System ACLs in the Back End.

• Click OK to close the Permissions for Folder window.

• Click OK to store the updated settings.

For further details about setting ACLs, see the Windows documentation.

File System ACLs in the Back End

Samba stores the file system permissions in extended file system access control lists (ACL) and in an extended attribute. For example:

• To list the extended ACLs of the /srv/samba/Demo/ directory, enter:

• To list the security.NTACL extended attribute of the /srv/samba/Demo/ directory, enter:

The previous example of file system ACLs and the extended attribute is mapped to the following Windows ACLs: