У меня есть сервер LTS Ubuntu 10.04.4 рабочий Samba, и соединенный с нашим доменом Active Directory с помощью PBIS (раньше аналогично открытый.) Samba настроен, чтобы сделать аутентификацию с помощью AD пользователей/групп, и это работает правильно. Кроме того, стандартные полномочия Linux (пользователь, группа, другие) мир правильно с Samba. НО, Samba, кажется, полностью игнорирует любой набор полномочий с расширенным ACLs.
Я попробовал различные smb.conf конфигурации, которые я видел рекомендуемый в другом месте, и ни один из них, кажется, не имеет никакого эффекта.
Установка машины:
[shared] comment = , nt acl support = yes admin users = force user = force group = \domain^users create mask = 0770 directory mask = 0770
workgroup = dns proxy = no server string = load printers = no cups options = raw guest account = pcguest log file = /var/log/samba/%m.log max log size = 50 security = ADS realm = socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 interfaces = 172.16.0.20 10.4.1.20 127.0.0.1 bind interfaces only = yes idmap uid = 16777216-33554431 idmap gid = 16777216-33554431 map to guest = Bad User
idmap backend = idmap_rid:=16777216-33554431 nt acl support = yes inherit acls = Yes map acl inherit = Yes map archive = no map hidden = no map read only = no map system = no store dos attributes = yes inherit permissions = Yes template shell = /bin/false winbind use default domain = no
Что я пропускаю здесь, чтобы заставить Samba работать с расширенным ACLs?
У меня есть папка в доле самбы. Сама доля является широко открытой в нашем домене ("действительные пользователи", устанавливающие, установлен на группу "Пользователей домена" для домена AD.) В той доле у меня есть папка с более строгими полномочиями на уровне файловой системы (принадлежавший одному AD пользователю с набором группы AD группе со всего несколькими людьми в нем и chmod-редактором полномочий к 770)
Проблема, я должен предоставить доступ к той папке другой AD группе, таким образом, я работаю "setfacl-m u:: rwx", чтобы дать им разрешение получить доступ к нему. Это работает в рамках Linux (если я ssh, в котором один из тех пользователей и перешли к папке)..., но если я соединяюсь с долей SMB с тем же самым пользователем, и пытаются перейти к той папке, доступ запрещен.
Опаздывая с этим вопросом, я все же хотел бы указать на официальную документацию Samba для поддержки ACL . Это справедливо для Samba 4.0.0 и более поздних версий, которые, безусловно, не были доступны в то время, когда задавался этот вопрос. Но поскольку вопрос появляется в поисковых системах, эта ссылка может быть полезной.
Основные шаги:
1. Убедитесь, что файловая система поддерживает acls (в настоящее время ext4 поддерживает по умолчанию, дополнительные параметры монтирования не требуются)
2. Убедитесь, что Samba скомпилирована с поддержкой ACL. (Да,по умолчанию в Ubuntu 14.04 LTS):
smbd -b | grep HAVE_LIBACL
3.
Включите ACL, установив следующее в разделе [global]
файла /etc/samba/smb.conf
:
vfs objects = acl_xattr
map acl inherit = yes
store dos attributes = yes
Для получения подробной информации посетите официальную документацию по ссылке выше.
Это потому, что заставляет пользователя
, заставляет группу
, создает маску
и маску каталога
заставляет использовать разрешения в стиле tradidional unix, которые не могут быть объединены с наследуемыми ACL.
ACL по умолчанию должны находиться на уровне файловой системы папки, а не самого ресурса samba, чтобы наследование работало, но имейте в виду, что противоречивые разрешения всегда будут запрещать доступ, например. Если у пользователя есть разрешение как у пользователя, но не как у группы samba, доступ будет запрещен при использовании ACL (что мне кажется ошибкой), например: пользователь никто не входит в группу nogroup , то ACL должны никому не разрешать & nogroup write permission, в противном случае доступ на запись будет запрещен. Только самба ведет себя таким образом!
Возможным способом создания папки с наследственными правами по умолчанию может быть:
me@myHost:/shares$ getfacl myShare/
# file: myShare/
# owner: JohnDoe
# group: domain\040users
user::rwx
group::rwx #effective:r-x
group:domain\040users:rwx #effective:r-x
group:domain\040admins:rwx #effective:r-x
mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:domain\040users:rwx
default:group:domain\040admins:rwx
default:mask::rwx
default:other::r-x
Раздел со значениями default:*
является интересной частью для наследования, потому что любой новый файл или папка получит их при создании внутри папки myShare. Подробнее об установке значений по умолчанию: в файле или папке смотрите страницу руководства setfacls. Теперь проблема с использованием создайте маску
или маску каталога в папке со значением по умолчанию:ACLs заключается в том, что samba затем переопределит эти значения по умолчанию, и в большинстве случаев эти операторы маски полезны только в том случае, если нужно, чтобы вся папка и файлы содержали только одного владельца и группу. ACL сложнее настраивать, но они предлагают гораздо больше гибкости, как обычно на машинах windows.
Чтобы samba соблюдала эти
должны быть установлены в разрешения по умолчанию:*::
наследуемые acls[global]
разделе:
[global]
; Important if ACLs (eg: setfacl) contain default entries
; which samba honors only if this is set to 'yes'.
inherit acls = yes
[...]
[myShare]
comment = Put your files here
path = /shares/myShare
writeable = yes
Это позволило бы создать общий ресурс, где каждый может записывать в общий ресурс... но (!). что не обязательно означает, что это разрешено на уровне файловой системы, потому что папка myShare просто разрешает пользователям домена . В любом случае, для паранойи разрешения на общий доступ можно сузить, разрешив только определенные группы:
write list = @"domain users"
, что подразумевает writeable=yes
, но только для групп, определенных в списке write list. Убедитесь, что разрешения на общий доступ и на папку не содержат противоречий, например:
write list = @"other group"
позволит другой группе записывать в общий доступ, но поскольку папки myShare позволяют записывать только пользователям домена , то очевидно, что это не удастся.