Linux samba create mask

SAMBA: организация доступа к подпапкам через единую точку входа

Задача: обеспечить такой общий доступ к файлам с помощью SAMBA, чтобы люди с других машин могли через специальную папку common заходить в только им разрешённые подпапки этой директории folderA и folderB, причём и у файлов и у папок требовалось обеспечить права по маске 770. То есть пользователи одной папки должны были иметь право работать со всеми документами в этой папке, независимо от того, кто их создал. Требовалось также запретить прямой доступ к подпапкам минуя основную с внешних компьютеров.

Таким образом, иерархия папок выгядит следующим образом:

common
— folderA
— folderB

В процессе решения задачи оказалось, что со вложенными папками SAMBA работает по только ей ведомым алгоритмам и всё то, что понаписано в манах, к ним практически не применимо за небольшими исключениями. Тем не менее, постом и молитвою удалось сотворить работоспособный конфиг, в котором выполняются все вышеуказанные требования.

Вот этот конфиг (/etc/samba/smb.conf):

[global]
workgroup = WORKGROUP
security = user
guest ok = no

[common]
path = /var/samba
valid users = @everybody
force group = +everybody
writeable = yes
create mask = 0660
force create mode = 0110
directory mask = 0770

[folderA]
path = /var/samba/folderA
valid users = @users_folderA
force group = +users_folderA
browseable = no

[folderB]
path = /var/samba/folderB
valid users = @users_folderB
force group = +users_folderB
browseable = no

Здесь три группы пользователей: everybody, users_folderA и users_folderB.
Пользователей, допустим, тоже 3: den, sam и alex.
Пользователям den и sam разрешено пользоваться только папкой users_folderA, а пользователю alex — только папкой users_folderB. Путь в эти подпапки лежит через папку common (/var/samba), поэтому все пользователи включены в отдельную группу everybody. Она является своего рода точкой начального входа для уполномоченных пользователей.

Сохраняем конфиг, проверяем его и перезапускаем SAMBA:

# testparm
# service smbd restart
# service nmbd restart

Теперь разберёмся с организацией папок и прав на них.

Права необходимо выставить следующие:

# chown root:everybody /var/samba
# chmod 770 /var/samba
# chown root:users_folderA /var/samba/folderA
# chmod 2770 /var/samba/folderA
# chown root:users_folderB /var/samba/folderB
# chmod 2770 /var/samba/folderB

Тем самым мы запрещаем всем кроме членов уполномоченной группы everybody просматривать и создавать файлы в папке common и всех её подпапках как с внешних узлов, так и из внутреннего шелла.

При этом, как ни странно, права при создании файлов и подпапок во внутрених папках folderA и folderB наследуются из прав, прописанных в секции [common] для родительской папки. Более того, их уже не обязательно явно указывать в подсекциях [folderA] и [folderB] — они просто игнорируются.

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

Директива force create mode = 0110 необходима для того, чтобы дополнтельно выставить на вновь создаваемые файлы executable бит для владельца и группы, который не выставляется директивой create mask. Директива force create mode действует по принципу ИЛИ с основной маской доступа, и выставляет бит в том случае, если он не выставлен директивой create mask.

Директива force group = +подгруппа запрещает доступ к папкам всем, кто не входит в эту подгруппу. Честно говоря, не понимаю, каким образом пользователь, не входящий в подгруппу, вообще мог бы получить какой-либо доступ к соответствующей подпапке, однако лишняя предосторожность не помешает.

Директива writable = yes в главной секции разрешает запись в основную папку common, но в то же время жёстко задаёт права записи и в подпапки этой папки, которые невозможно переопределить во внутренних секциях. Это странное наследование правил записи разрешает запись в подпапках folderA и folderB только в том случае, если вы пришли к ним через родительскую папку common. Если же попытаться обратиться к подпапкам напрямую, то они окажутся доступными только для чтения и даже уполномоченные пользователи подгрупп ничего не смогут сделать с содержимым этих подпапок.

Директива browsable = no вообще скрывает подпапки из прямой видимости извне. Поэтому, когда вы просматриваете сетевое окружение с других компьютеров, вы увидите только папку common.

Таким образом, задача полностью решена, однако некоторые особенности SAMBA никак не соотносятся с тем, что написано в её man-ах, а то и противоречат им.

Источник

Как Samba формирует права на создаваемые в шаре файлы/каталоги?

[ 1. ДАНО ]
Домашняя ЛВС.
Сервер — Ubuntu Server 16.04.1 и Samba 4.3.11.
Клиенты — Win7Pro (учётка amok — в Самбе/Убунте есть), WinXP (учётка XPMUser — в Самбе/Убунте отсутствует).

[ 2. ЗАДАЧА ]
Сделать общедоступную шару для win-клиентов с полным беспределом: все могут всё (создавать файлы и каталоги любого уровня вложенности, удалять всё, запускать *.exe).

[ 3. ЧТО СДЕЛАНО ]
Создал каталог /usr/local/samba_shara, сменил пользователя/группу на nobody/nogroup и выставил ему права 0777.

1. Создаю с win-клиента известной Самбе учёткой amok в шаре новый файл и каталог
2. Копирую с win-клиента известной Самбе учёткой amok в шару существующий файл и каталог
3. Создаю с другого win-клиента не известной Самбе учёткой XPMUser в шаре новый файл и каталог
4. Копирую с другого win-клиента не известной Самбе учёткой XPMUser в шару существующий файл и каталог

Как видно, в требуемые 0777 попадают не все файлы/каталоги! Более того, для каталогов с точки зрения итоговых прав доступа есть разница кто их создаёт/копирует — amok или XPMUser! Но и это не всё — Самба ещё умудряется различать скопированный и созданный именно amok’ом файлы.

При создании amok‘ом нового файла в шаре из лога /var/log/samba/log.MACHINE удалось выудить это:

При создании amok‘ом нового каталога в шаре из лога /var/log/samba/log.MACHINE удалось выудить это:

1. Почему несмотря на заданную опцию force user права доступа вновь создаваемых файлов/каталогов зависят от того, из-под какой именно win-учётки их создают?
2. Каков алгоритм формирования итоговых прав вновь создаваемых в шаре Самбы файлов/каталогов (где задаются и от чего зависят изначальные права; количество и порядок наложения масок самой Самбы на эти права; участвует ли тут файловая система Убунты со своим umask, если да, то на каком этапе; участвует ли клиентская Windows)? Почему при заданных опциях «force create mode = 0777» и «force directory mode = 0777» итоговые права отличны от 0777?
3. Где найти свежий/нормальный/с_примерами список-описание опций smb.conf (ru/eng)? Этот видел.

Помогите, пожалуйста, решить данную, как мне сначала казалось — простейшую, задачу. Без нормальной теоретической подготовки я могу ещё долго безрезультатно проводить натурные эксперименты и заниматься хернёй высчитывая от балды побитово права и umask’и 🙁

P. S. Был удивлён, что log level = 10 Самбы стабильно «вешает» tail -f 🙂

Источник

Установка и настройка файлового сервера Samba на CentOS 8

Samba позволяет настроить файловое хранилище различных масштабов — от малых офисов для крупных организаций. В данной инструкции мы рассмотрим процесс настройки файлового сервера. Сначала мы выполним установку и базовую настройку с предоставлением гостевого доступа. После будет приведены примеры разграничения доступа по пользователям, группам и пользователям Active Directory.

Подготовка сервера

1. Время

Для корректного отображения дат, необходимо позаботиться о синхронизации времени. Для этого будем использовать демон chrony. Установим его:

dnf install chrony

Разрешим автозапуск и стартанем сервис:

systemctl enable chronyd

systemctl start chronyd

2. Брандмауэр

По умолчанию, в системах CentOS брандмауэр (firewalld) запрещает все соединения. Необходимо разрешить сервис samba. Также в нашей системе может использоваться система управления брандмауэром iptables. Рассмотрим оба варианта.

а) Если используется firewalld.

firewall-cmd —permanent —add-service=samba

б) Если используется iptables.

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

iptables -I INPUT -p tcp —dport 445 -j ACCEPT

iptables -I INPUT -p udp —dport 137:138 -j ACCEPT

iptables -I INPUT -p tcp —dport 139 -j ACCEPT

* где порт 445 используется для samba, а порты 137, 138 и 139 — для работы NetBIOS (использование имени компьютера для доступа).

service iptables save

3. SELinux

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

dnf install policycoreutils setroubleshoot

Теперь создаем само правило. Например, если мы планируем использовать каталог /data, то вводим команды:

* на случай, если каталога еще нет, создаем его.

semanage fcontext -a -t samba_share_t «/data(/.*)?»

restorecon -R -v /data

Установка и запуск Samba

Установка выполняется из репозитория одной командой:

dnf install samba

Разрешаем автостарт сервиса и запускаем его:

systemctl enable smb —now

И проверим, что сервис запустился:

systemctl status smb

Проверяем, что сервер самба позволяет к себе подключиться. Для этого можно с компьютера обратиться к серверу по SMB, например, на компьютере с Windows это можно сделать из проводника, прописав путь к серверу с двух слэшей:

* в данном примере мы подключаемся к серверу Samba с IP-адресом 192.168.1.15.

Если мы настроили сервер правильно, система должна запросить пароль на подключение к Samba. Отказываемся его вводить. На данном этапе проверка закончена.

Создание первой шары и предоставление к ней гостевого доступа (анонимного)

Разберем самый простой пример предоставления доступа к папке — анонимный доступ всем пользователям без запроса пароля.

Открываем на редактирование конфигурационный файл samba:

В секцию [global] добавляем:

.
map to guest = Bad Password
.

И добавляем настройку для общей папки:

[Общая папка]
comment = Public Folder
path = /data/public
public = yes
writable = yes
read only = no
guest ok = yes
create mask = 0777
directory mask = 0777
force create mode = 0777
force directory mode = 0777

• [Общая папка] — имя общей папки, которое увидят пользователи, подключившись к серверу.
• comment — свой комментарий для удобства.
• path — путь на сервере, где будут храниться данные.
• public — для общего доступа. Установите в yes, если хотите, чтобы все могли работать с ресурсом.
• writable — разрешает запись в сетевую папку.
• read only — только для чтения. Установите no, если у пользователей должна быть возможность создавать папки и файлы.
• guest ok — разрешает доступ к папке гостевой учетной записи.
• create mask, directory mask, force create mode, force directory mode — при создании новой папки или файла назначаются указанные права. В нашем примере права будут полные.

Создаем каталог на сервере и назначим права:

mkdir -p /data/public

chmod 777 /data/public

Применяем настройки samba, перезагрузив сервис:

systemctl restart smb

Пробуем подключиться к папке. Мы должны зайти в нее без необходимости ввода логина и пароля.

Доступ к папке по логину и паролю

Теперь создадим каталог, в который вход будет разрешен только авторизованным пользователям.

Открываем конфигурационный файл samba:

Добавляем настройку для новой папки:

[Папка сотрудников]
comment = Staff Folder
path = /data/staff
public = no
writable = yes
read only = no
guest ok = no
create mask = 0777
directory mask = 0777
force create mode = 0777
force directory mode = 0777

* эти настройки, во многом, похожи на те, что использовались в примере выше. Вот основные различия:

• path = /data/staff — используем новый путь до папки.
• public = no — запрещаем публичный доступ.
• guest ok = no — не разрешаем гостевое подключение.

Создаем каталог для новой папки:

Задаем права на созданный каталог:

chmod 777 /data/staff

Создаем пользователя в системе Linux:

* где staff1 — имя пользователя.

Задаем пароль для пользователя:

Теперь создадим пользователя в samba:

smbpasswd -a staff1

systemctl restart smb

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

Если мы авторизованы на компьютере, с которого пытаемся подключиться к серверу, под той же учетной записью, что создали для доступа к папке, samba может и не потребовать аутентификации.

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

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

Открываем конфигурационный файл samba:

Добавляем настройку для новой папки:

[Приватная папка]
comment = Private Folder
path = /data/private
public = no
writable = no
read only = yes
guest ok = no
valid users = admin, staff2, staff3, @privateusers
write list = admin, staff2
create mask = 0777
directory mask = 0777
force create mode = 0777
force directory mode = 0777
inherit owner = yes

* стоит обратить внимание на следующие настройки:

• path = /data/private — используем новый путь до папки.
• writable = no и read only = yes — в данном примере мы разрешим запись в каталог только некоторым пользователям. Поэтому общие настройки, разрешающие запись в папку, должны быть запрещены.
• valid users — список пользователей, которым разрешено подключаться к каталогу. В данном примере разрешения работают для пользователей admin, staff2 и staff3, а также для всех, кто входим в группу privateusers.
• write list — список пользователей, которые имеют доступ к папке на чтение и запись. В данном примере мы разрешаем это только для пользователей admin и staff2.
• inherit owner — опция позволяем включить наследование владельца при создании папок и файлов.

* если мы хотим, чтобы доступ к каталогу был полный у определенных пользователей (без разделения на тех, кто может только читать и тех, кто может также писать в папку), то опцию write list можно не указывать, а опции writable и read only оставить как в примерах выше.

Создаем каталог для новой папки:

Задаем права на созданный каталог:

chmod 777 /data/private

Для применения настроек перезапускаем samba:

systemctl restart smb

Проверяем возможность работы с новым каталогом.

Авторизация с Active Directory

Разберем пример конфигурирования файлового сервера samba в домене Windows и настроим авторизацию пользователей на базе LDAP Active Directory.

Подключение к Active Directory

Введем наш сервер в домен. Сначала необходимо убедиться, что сервер доступен по своему доменному имени. Если серверу так и не было задано вменяемого имени, вводим команду:

hostnamectl set-hostname samba.dmosk.local

* где samba — имя сервера; dmosk.local — домен.

После добавляем в DNS наш сервер samba. Ждем минут 15, если у нас используется доменная инфраструктура с несколькими сайтами.

Устанавливаем необходимые компоненты:

dnf install samba-client samba-winbind samba-winbind-clients krb5-workstation

Открываем конфигурационный файл samba:

В разделе [global] редактируем следующие опции:

workgroup = DMOSK
security = ads

* где DMOSK — NETBIOS имя домена; ads — указывает, что для samba будет использоваться модель безопасности LDAP Active Directory.

Также в [global] добавим следующие строки:

kerberos method = secrets and keytab
realm = DMOSK.LOCAL
winbind enum groups = Yes
winbind enum users = Yes
idmap config * : rangesize = 1000000
idmap config * : range = 1000000-19999999
idmap config * : backend = autorid

• kerberos method — метод проверки kerberos. В данном примере сначала используется secretts.tdb, а затем системная таблица ключей.
• realm — сервер Active Directory. В нашем примере прописан домен, так как по нему можно обратиться к любому из серверов AD.
• winbind enum groups — задает пределы перечисления групп через setgrent(), getgrent() и endgrent().
• winbind enum users — задает пределы перечисления пользователей через setpwent(), getpwent()и endpwent().
• idmap config * : rangesize — определяет количество доступных uids и gids в каждом доменном диапазоне.
• idmap config * : range — определяет доступные совпадающие диапазоны uid и gid, для которых серверная часть является авторитетной.
• idmap config * : backend — задает idmap плагин для использования в качестве SID/uid/gid подсистемы

Вводим сервер в домен:

net ads join -U Administrator@dmosk.local

* где Administrator — учетная запись пользователя AD с правами на ввод компьютеров в домен; dmosk.local — наш домен.

Мы должны увидеть, примерно, следующее:

Using short domain name — DMOSK
Joined ‘SAMBA’ to dns domain ‘dmosk.local’

Разрешаем автозапуск winbind и стартуем его:

systemctl enable winbind —now

Выбираем профиль для аутентификации:

authselect select winbind —force

Проверяем, что наш сервер может получить список пользователей Active Directory:

Если мы увидели список пользователей и групп, то присоединение сервера к домену завершено.

Настройка шары

Открываем конфигурационный файл samba:

[AD]
comment = Folder for AD users
path = /data/ad
public = no
writable = yes
read only = no
guest ok = no
valid users = «@DMOSK\Domain Users» «@DMOSK\Domain Admins»
create mask = 0777
directory mask = 0777
force create mode = 0777
force directory mode = 0777
inherit owner = yes

* в данном примере мы будем шарить папку на сервере /data/ad; мы предоставим доступ всем пользователям групп Domain Users и Domain Admins домена DMOSK.

Создаем каталог и задаем права:

chmod 777 /data/ad

Теперь можно перезапустить самбу:

systemctl restart smb

Пробуем подключиться к серверу. У нас должна появиться еще одна папка ad.

Права ACL

И в продолжение разговора о интеграции с AD, попробуем настроить ACL для более тонкого предоставления прав доступа.

Для этого снова открываем конфигурационный файл samba:

В раздел [global] добавим:

acl compatibility = auto

. и создадим новую шару:

[AD ACL]
comment = Folder for AD ACL
path = /data/adacl
public = no
writable = yes
read only = no
guest ok = no
admin users = «@DMOSK\Domain Admins»
inherit acls = yes
inherit owner = yes
inherit permissions = yes
map acl inherit = yes

* где admin users — пользователи, которые могут менять права папки; inherit acls — наследование acl прав; inherit permissions — наследование прав от папки родителя; map acl inherit — использовать ли схему контроля доступа, хранимую в Windows ACL.

Создаем каталог и задаем права:

chmod 777 /data/adacl

systemctl restart smb

Подключаемся к нашей созданной общей папке. Кликаем по ней правой кнопкой мыши — выбираем свойства. На вкладке «Безопасность» мы можем менять права:

Сетевая корзина

При удалении файлов из общей папки, данные удаляются навсегда. Но мы можем настроить сетевую корзину — скрытый каталог, в который будут перемещаться удаляемые с самбы объекты.

Открываем конфигурационный файл:

[Recycle]
comment = Snap Directories
path = /data/recycle
public = yes
browseable = yes
writable = yes
vfs objects = recycle
recycle:repository = .recycle/%U
recycle:keeptree = Yes
recycle:touch = Yes
recycle:versions = Yes
recycle:maxsize = 0
recycle:exclude = *.tmp,

• vfs objects = recycle — использовать подсистему recycle.
• recycle:repository — где хранить удаленные объекты. В данном примере удаленные файлы попадут в скрытый каталог .recycle к котором создастся каталог с именем пользователя, удалившего файл или папку.
• recycle:keeptree — удалять объекты с сохранение дерева каталогов.
• recycle:touch — изменить ли дату изменения файла при его перемещении в корзину.
• recycle:versions — при удалении файлов с совпадающими именами, добавлять номер версии.
• recycle:maxsize — не помещать в корзину файлы, размер которых больше заданного параметра (в байтах). В данном примере, помещать файлы любого размера.
• recycle:exclude — исключить файлы.
• recycle:exclude_dir — исключить каталог.

Создаем каталог и задаем права:

chmod 777 /data/recycle

systemctl restart smb

Пробуем зайти в сетевой каталог Recycle и создать, а после удалить файл. Он должен оказаться к скрытой папке .recycle.

Для автоматической чистки сетевой корзины можно создать скрипт:

/usr/bin/find $recyclePath -name «*» -ctime +$maxStoreDays -exec rm <> \;

* в данном скрипте мы ищем все файлы в каталоге /data/recycle/.recycle, которые старше 30 дней и удаляем их.

Разрешаем запуск скрипта:

chmod +x /scripts/cleanrecycle.sh

Создаем задание в планировщике:

0 5 * * * /scripts/cleanrecycle.sh

* в данном примере мы будем запускать скрипт по очистке сетевой корзины каждый день в 05:00.

Подключение к шаре

Теперь разберем примеры подключения к нашим шарам из разных систем.

Windows

Для разового подключения можно использовать проводник, прописав в нем адрес сервера через косые линии:

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

В открывшемся окне прописываем путь до сетевой папки и выбираем имя диска:

Сетевой диск настроен.

Но мы может сделать те же действия из командной строки:

net use x: \\samba.dmosk.local\AD ACL /persistent:yes

* где x: — имя сетевого диска; \\samba.dmosk.local\AD ACL — путь до сетевого каталога; persistent:yes — указывает на то, что нужно восстанавливать данный диск каждый раз при входе в систему.

Linux

Монтирование

В Linux мы можем монтировать удаленный каталог с помощью команды mount, например:

mount -t cifs «//192.168.1.15/ad» /mnt -o user=dmosk

* где 192.168.1.15 — IP-адрес сервера; mnt — каталог, куда монтируем сетевую шару; dmosk — пользователь, под которым выполняем подключение к сетевому каталогу.
** в систему должен быть установлен пакет cifs-utils.

Подробнее, процесс монтирования описан в инструкции Как в Linux монтировать шару CIFS.

SMB Browser

Также мы можем увидеть содержимое удаленных папок на samba при помощи клиента smb. Для начала установим данного клиента:

а) на Red Hat / CentOS / Fedora:

yum install samba-client

б) на Debian / Ubuntu / Mint:

apt-get install samba-client

После вводим команду:

smbclient -L 192.168.1.15 -U staff@dmosk.local

* где 192.168.1.15 — сервер samba, к которому мы пытаемся подключиться; staff@dmosk.local — учетная запись, под которой выполняется подключение.

. мы получим список каталогов, которые расшарены на сервере.

Также мы можем подключиться к конкретной папке, например:

smbclient \\\\192.168.1.15\\ad -U staff@dmosk.local

Мы подключимся клиентом samba — можно выполнить запрос на показ содержимого:

Или полный список возможных команд:

Некоторые опции Samba

Рассмотрим некоторые полезные опции, которые могут пригодится при настройке Samba.

1. hosts allow

Параметр задает список разрешенных хостов или сетей, с которых можно подключаться к серверу. Если его прописать в секцию с настройкой шары, то он будет действовать только для нее, если прописать в [global], то для всех общих папок.

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

hosts allow = comp1, 192.168.1., 192.168.160.0/255.255.252.0

* в нашем примере мы разрешим доступ только для компьютера comp1, компьютеров из сетей 192.168.1.0/24 и 192.168.160.0/22.

2. hosts deny

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

hosts deny = comp2, 192.168.2., 192.168.164.0/255.255.252.0

hosts deny = ALL EXCEPT 192.168.3.

3. interfaces

По умолчанию samba использует все сетевые интерфейсы, кроме локальной петли (127.0.0.1). Параметр interfaces позволит указать, на каком сетевом адаптере файловый сервер должен принимать запросы. Пример:

interfaces = ens32 192.168.1.15/24 192.168.2.15/255.255.255.0

4. Force User/Group

Опции force user и force group позволяют задать пользователя и группу, от которых будет работать подключение пользователя к samba. Параметр может оказаться полезным для создания шары из каталога с уже назначенным владельцем, которого мы не хотим менять.

Прописывается для шары:

force user = apache
force group = apache

* данная настройка позволит подключаться к шаре под пользователем apache.

Источник