Samba, игнорирующий POSIX ACLs

У меня есть сервер LTS Ubuntu 10.04.4 рабочий Samba, и соединенный с нашим доменом Active Directory с помощью PBIS (раньше аналогично открытый.) Samba настроен, чтобы сделать аутентификацию с помощью AD пользователей/групп, и это работает правильно. Кроме того, стандартные полномочия Linux (пользователь, группа, другие) мир правильно с Samba. НО, Samba, кажется, полностью игнорирует любой набор полномочий с расширенным ACLs.

Я попробовал различные smb.conf конфигурации, которые я видел рекомендуемый в другом месте, и ни один из них, кажется, не имеет никакого эффекта.

Установка машины:

  • Доля файлов находится на своем собственном диске. Смонтируйте, что информация от/etc/fstab для диска:
    • UUID=372aa637-4b7b-45cc-8340-9d028893c196/media/news-drive ext4 user_xattr, acl 0 2
  • Машина соединена с доменом с помощью PBIS (раньше аналогично открытый)
  • Конфигурация Samba для доли:
[shared]
   comment = , 
   nt acl support = yes
   admin users = 
   force user = 
   force group = \domain^users
   create mask = 0770
   directory mask = 0770
  • Глобальная конфигурация Samba
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 с тем же самым пользователем, и пытаются перейти к той папке, доступ запрещен.

3
задан 20 December 2012 в 00:15
2 ответа

Опаздывая с этим вопросом, я все же хотел бы указать на официальную документацию 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

Для получения подробной информации посетите официальную документацию по ссылке выше.

5
ответ дан 3 December 2019 в 05:29

Это потому, что заставляет пользователя , заставляет группу , создает маску и маску каталога заставляет использовать разрешения в стиле 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 позволяют записывать только пользователям домена , то очевидно, что это не удастся.

1
ответ дан 3 December 2019 в 05:29

Теги

Похожие вопросы