Created attachment 17314 [details] Скрины с правами AD на Windows server 2019 с Administrative Templates (.admx) for Windows 10 October 2022 Update (22H2) и admx-basealt-master 0.1.13.6-alt1, ALT Workstation K 10.4 Kernel: Linux 6.1.115-un-def-alt1, версия gpupdate-0.11.4-alt1.noarch. Файловый сервер на Windows server 2019, autofs-5.1.8-alt4.x86_64, групповые политики настроены по данной инструкции https://docs.altlinux.org/ru-RU/domain/10.4/html/group-policy/drives.html Имеется общий файлообменник, на который все пользователи организации имеют права на чтение, в данном файлообменнике каждая служба имеет свою папку с полными правами, при подключении сетевого ресурса через gpo (autofs), после создания пользователем паки в своем подразделении, не может работать внутри созданной им папки, ему необходимо дать предварительно себе же права для работы внутри созданной им же папкой, не смотря на то, что унаследование предоставлены для этой папки и ее подпапок и файлов группе пользователей состоящим в данном подразделении. При работе из под windows таких проблем не возникает. Для наглядности прикладываю скрины, слева права на папку созданная из под линукс, справа из под windows, и второй скрин когда пользователь из под линукс заходит из проводника с адресной строки smb://fileserver/folder с указанием своих учетных прав, при таком подключении у пользователя из под линукс есть положенные права без ограничений нарушений прав унаследования как из под windows.
Стенд - ALT Workstation 11 (Sisyphus) - Windows Server 2019 Версия - gpupdate-0.11.4-alt1 - autofs-5.1.9-alt3 Шаги воспроизведения TLDR: связано с опцией cifsacl 1. Создать пару подразделений (OU1, OU2). 2. Создать по группе для данных подразделений соответственно (group_ou1, group_ou2) 3. Создать по пользователю для данных подразделений соответственно (user_ou1, user_ou2). 4. Добавить данных пользователей в только что созданные группы соответственно (user_ou1 в group_ou1, user_ou2 в group_ou2). 5. Создать сетевую шару на сервере (C:/share) с правами чтения для всех. 6. Создать подпапки для с доступом Чтение и запись только для созданных групп. 1. C:/share/ou1 для group_ou1 2. C:/share/ou2 для group_ou2 7. Согласно документации 10.5.7. Подключение сетевых дисков (https://docs.altlinux.org/ru-RU/domain/10.4/html/group-policy/drives.html) настроить сетевой диск для C:/share (пользовательская политика). 8. Применить групповые политики: # gpupdate && gpoa и $ gpupdate. 9. Войти пользователем user_ou1 на тестовой машине. 10. В файловом менеджере перейти по пути /run/media/user_ou1/drives/share/ou1 11. Создать папку user_ou1. 12. Проверить права созданной папки: # stat /run/media/user_ou1/drives/share/ou1/user_ou1/ -c %A Ожидаемый результат: папка доступна на чтение и запись. Фактический результат: папка недоступна на чтение и запись (d---------). Сравните права в данной примере 1 - созданная папка с правами # stat /run/media/user_ou1/drives/share/ou1/ -c %A drwx-----T 2 - созданная доменным пользователем в данной папке # stat /run/media/user_ou1/drives/share/ou1/user_ou1/ -c %A d--------- При создании папки из под Windows права не изменяются, то есть наследование прав не работает: # stat /run/media/user_ou1/drives/share/ou1/win_user_ou1 -c %A d--------- Дополнительно: если убираю опцию cifsacl, то всё выглядит корректно: # echo '+dir:/etc/auto.test' >> /etc/auto.master # mkdir -p /etc/auto.test && \ echo '"share" -fstype=cifs,cruid=$USER,sec=krb5,noperm ://dc/share' > /etc/auto.test/test.conf && \ echo '/mnt/testcifs /etc/auto.test/test.conf --browse' > /etc/auto.test/test.autofs # systemctl restart autofs.service $ stat /mnt/testcifs/share/ou1/user2_ou1/ -c %A drwxr-xr-x $ mkdir -p /mnt/testcifs/share/ou1/new/ && \ stat /mnt/testcifs/share/ou1/new/ -c %A drwxr-xr-x Воспроизводится в P10
Добрый день! Можно уточнить ориентировочные сроки по разрешению данной проблемы?
(In reply to Evgeny Shesteperov from comment #1) > Стенд > > - ALT Workstation 11 (Sisyphus) > - Windows Server 2019 > > Версия > > - gpupdate-0.11.4-alt1 > - autofs-5.1.9-alt3 > > Шаги воспроизведения > > TLDR: связано с опцией cifsacl > > 1. Создать пару подразделений (OU1, OU2). > 2. Создать по группе для данных подразделений соответственно > (group_ou1, group_ou2) > 3. Создать по пользователю для данных подразделений соответственно > (user_ou1, user_ou2). > 4. Добавить данных пользователей в только что созданные группы > соответственно (user_ou1 в group_ou1, user_ou2 в group_ou2). > 5. Создать сетевую шару на сервере (C:/share) с правами чтения для > всех. > 6. Создать подпапки для с доступом Чтение и запись только для созданных > групп. > 1. C:/share/ou1 для group_ou1 > 2. C:/share/ou2 для group_ou2 > 7. Согласно документации 10.5.7. Подключение сетевых дисков > > (https://docs.altlinux.org/ru-RU/domain/10.4/html/group-policy/drives.html) > настроить сетевой диск для C:/share (пользовательская политика). > 8. Применить групповые политики: # gpupdate && gpoa и $ gpupdate. > 9. Войти пользователем user_ou1 на тестовой машине. > 10. В файловом менеджере перейти по пути > /run/media/user_ou1/drives/share/ou1 > 11. Создать папку user_ou1. > 12. Проверить права созданной папки: > # stat /run/media/user_ou1/drives/share/ou1/user_ou1/ -c %A > > Ожидаемый результат: папка доступна на чтение и запись. > > Фактический результат: папка недоступна на чтение и запись (d---------). > > Сравните права в данной примере > > 1 - созданная папка с правами > > # stat /run/media/user_ou1/drives/share/ou1/ -c %A > drwx-----T > > 2 - созданная доменным пользователем в данной папке > > # stat /run/media/user_ou1/drives/share/ou1/user_ou1/ -c %A > d--------- > > При создании папки из под Windows права не изменяются, то есть > наследование прав не работает: > > # stat /run/media/user_ou1/drives/share/ou1/win_user_ou1 -c %A > d--------- > > Дополнительно: если убираю опцию cifsacl, то всё выглядит корректно: > > # echo '+dir:/etc/auto.test' >> /etc/auto.master > # mkdir -p /etc/auto.test && \ > echo '"share" -fstype=cifs,cruid=$USER,sec=krb5,noperm ://dc/share' > > /etc/auto.test/test.conf && \ > echo '/mnt/testcifs /etc/auto.test/test.conf --browse' > > /etc/auto.test/test.autofs > # systemctl restart autofs.service > $ stat /mnt/testcifs/share/ou1/user2_ou1/ -c %A > drwxr-xr-x > $ mkdir -p /mnt/testcifs/share/ou1/new/ && \ > stat /mnt/testcifs/share/ou1/new/ -c %A > drwxr-xr-x > > > Воспроизводится в P10 Без использования autofs, с ручным монтированием -- работает ?
Да, при подключении через проводник Dolphin проблем никаких нет, я для удобства сделал типа внутрикорпоративного сайта чтобы оттуда подключали по ссылке, только что приходится учетные данные вводить с указанием fqnd, по регламенту пользователям приходится менять пароли каждые 3 месяца, это неудобно для пользователей, ну и вызывает проблему для определенных пользователей.
У нас в cifs воспроизводится подобная проблема и на каталоге и на файлах. По каталогу после создания его не видно, но если создать ещё раз то скажет что такой каталог уже существует И файл также кто работал с ним его не видит, на соседнем компьютере его видно. Перезагрузка ПК помогает увидеть всё что ищут
Здравствуйте Сергей, исправление попадет в gpupdate версии 0.12.2-alt1?
Предположу, что к gpupdate текущая проблема никакого отношения не имеет. Сравнивать монтирование шары через cifs или подключение через Dolphin (а также любой другой файловый менеджер) стоит так: 1) Подключение через файловый менеджер аналогично переходу по UNC-пути в Windows: smb://server/shara/directory (для сетевой папки \\server\shara\directory) 2) Монтирование шары через cifs соответствует подключению сетевого диска (autofs тут не имеет особого значения, он только автоматизирует подключение): X:\directory (к шаре \\server\shara) gpupdate делает второе, а вы пишите (если я правильно понял), что первое работает, а второе - нет. Так это разные механизмы и к gpupdate явно они не относятся. Версия autofs для монтирования шары через cifs не особо существенна. Существенна версия ядра и драйвер cifs.ko, который идёт в составе ядра. Могут быть существенны опции монтирования. Смотреть права в Dolphin, вообще, не имеет особого смысла - он просто так не умеет. Права применяются на сервере и, если там применено хитрое наследование, в рамках файловой системы NTFS, то через протокол SMB, в преобразованных правах в клиенте для сетевой файловой системы cifs, уже показывается оторванное от реальности на сервере состояние. Клиенты в Linux на умеют ничего, кроме чтения линуксовых прав, реальные права на файловой системе NTFS они не покажут, поэтому скрины нужно приводить с правами на виндовой шаре. Просто для того, чтобы воспроизвести проблему. При этом стоит учитывать, что для шары на линуксовом сервере Samba поведение и настройки будут, скорее всего, другими. Источник проблемы, скорее всего, в том, что линуксовый клиент неправильно "угадывает" созданные права на сервере, неправильно их задаёт в памяти после создания папки, но правильно их вычитывает после переподключения. Решение этой проблемы, так или иначе, сводится к исправлению кода ядра и драйвера cifs. Для полного анализа проблемы, её нужно описать в деталях для воспроизведения. И, прежде всего, так, чтобы правильно были настроены права на сервере. Желательны соответствующие скрины. Никаким обновлением gpupdate, скорее всего, эту проблему решить не удастся. Если только не подобрать дополнительные опции монтирования шары (подключения сетевого диска в термиологии windows). А для этого нужно не в Dolphin шару smb://server/shara/directory проверять, а через ручной mount: # mount -t cifs //server/shara /PATH_TO_MOUNTPOINT -o cruid=USERNAME,sec=krb5,noperm,cifsacl где USERNAME - это имя пользователя, для которого монтируется шара, а /PATH_TO_MOUNTPOINT - каталог, в который монтируется шара (аналог имени сетевого диска, только как подкаталог, где будет отображаться содержимое шары после успешного монтирования). Ещё один вариант - это задавать опции для шаблона настроек autofs в gpupdate в файле: /usr/share/gpupdate/templates/autofs_mountpoints.j2 Вот если удастся при отладке получить желаемое поведение теми или иными опциями монтирования, то эти опции можно добавить в gpupdate. А иначе текущая проблема - это недоработка драйвера cifs. И к самому gpupdate или вспомогательному инструменту autofs отношения не имеет.
Задача озаглавлена "Нарушение унаследования прав на сетевых ресурсах при использовании опции cifsacl". Правильно ли, что без использования опции cifsacl, проблема не возникает? Для проверки достаточно убрать эту опцию из файлов: $ grep -R cifsacl /usr/share/gpupdate/templates/ /usr/share/gpupdate/templates/autofs_mountpoints_hide.j2:"{{ drv.label }}" -fstype=cifs,cruid=$USER,sec=krb5,noperm,cifsacl :{{ drv.path }} /usr/share/gpupdate/templates/autofs_mountpoints_hide.j2:"{{ drv.dir }}" -fstype=cifs,cruid=$USER,sec=krb5,noperm,cifsacl :{{ drv.path }} /usr/share/gpupdate/templates/autofs_mountpoints.j2:"{{ drv.label }}" -fstype=cifs,cruid=$USER,sec=krb5,noperm,cifsacl :{{ drv.path }} /usr/share/gpupdate/templates/autofs_mountpoints.j2:"{{ drv.dir }}" -fstype=cifs,cruid=$USER,sec=krb5,noperm,cifsacl :{{ drv.path }} Далее, после переподключения (ну, или после ребута), этих опций не будет. Решает ли это заявленную проблему?
(Ответ для Evgeny Sinelnikov на комментарий #8) > Задача озаглавлена "Нарушение унаследования прав на сетевых ресурсах при > использовании опции cifsacl". Правильно ли, что без использования опции > cifsacl, проблема не возникает? > > Для проверки достаточно убрать эту опцию из файлов: > $ grep -R cifsacl /usr/share/gpupdate/templates/ > /usr/share/gpupdate/templates/autofs_mountpoints_hide.j2:"{{ drv.label }}" > -fstype=cifs,cruid=$USER,sec=krb5,noperm,cifsacl :{{ drv.path }} > /usr/share/gpupdate/templates/autofs_mountpoints_hide.j2:"{{ drv.dir }}" > -fstype=cifs,cruid=$USER,sec=krb5,noperm,cifsacl :{{ drv.path }} > /usr/share/gpupdate/templates/autofs_mountpoints.j2:"{{ drv.label }}" > -fstype=cifs,cruid=$USER,sec=krb5,noperm,cifsacl :{{ drv.path }} > /usr/share/gpupdate/templates/autofs_mountpoints.j2:"{{ drv.dir }}" > -fstype=cifs,cruid=$USER,sec=krb5,noperm,cifsacl :{{ drv.path }} > > Далее, после переподключения (ну, или после ребута), этих опций не будет. > > Решает ли это заявленную проблему? Здравствуйте Евгений, вы все абсолютно правильно поняли, без опции cifsacl проблем нет, при таком раскладе абсолютно свободно как и Widows гуляешь в обменниках с отключенным унаследованием прав на каталогах, Только я не знаю на сколько данный вариант приемлем, по данному багу у меня сейчас открыт тикет в техподдержке, где как вариант я предложил убирать скриптом данную опцию логон скриптом при выключении хоста после обновления Пример: #!/bin/bash # Автообновление apt-get update && apt-get dedup -y && apt-get dist-upgrade -y && update-kernel -y # Удаление опции cifsacl # Путь к файлу FILE_PATH="/usr/share/gpupdate/templates/autofs_mountpoints.j2" # Текст, который нужно вырезать TEXT_TO_REPLACE=",cifsacl" # Основная функция замены текста replace_text() { sed -i.bak "s/$TEXT_TO_REPLACE//g" "$FILE_PATH" } # Запуск функций replace_text И еще одно предложение, рассмотреть возможность реализации в ADMX шаблонах опцию включения или отключения типа cifsacl on (off) ели опция нужна будет в других случаях На данный момент для проверки я убрал на 3 хостах вручную данную опцию, всe вроде хорошо, но опять же повторюсь, на сколько корректный данный подход? Еще как альтернативу предложили на ваших еженедельных курсах по вторникам, рассмотреть вариант монтирования с помощью gio, но пока руки не дошли.
Евгений, хотел дополнить, что удаление опции произвел только в /usr/share/gpupdate/templates/autofs_mountpoints.j2", а не во всем представленном Вами перечне.
(Ответ для Murat на комментарий #9) > (Ответ для Evgeny Sinelnikov на комментарий #8) > > И еще одно предложение, рассмотреть возможность реализации в ADMX шаблонах > опцию включения или отключения типа cifsacl on (off) ели опция нужна будет в > других случаях > На данный момент для проверки я убрал на 3 хостах вручную данную опцию, всe > вроде хорошо, но опять же повторюсь, на сколько корректный данный подход? > Еще как альтернативу предложили на ваших еженедельных курсах по вторникам, > рассмотреть вариант монтирования с помощью gio, но пока руки не дошли. Добрый день, Мурат. В следующих версиях gpupdate и admx-basealt будет реализована политика и обработка отключения опции cifsacl.
gpupdate-0.13.0-alt1 -> sisyphus: Thu Mar 06 2025 Valery Sinelnikov <greh@altlinux> 0.13.0-alt1 - Implemented Local Administrator Password Solution (LAPS) functionality, including support for Group Policy Object (GPO) keys to configure LAPS settings - Added support for disabling cifsacl in autofs mounts (closes:52333) - Implemented the ability to merge computer and user GPO shortcuts - Added access restrictions to network directories of other users - Added cleaning functionality for the autofs configuration catalog - Added ability to configure KDE 6 files
Для including support for Group Policy Object (GPO) keys to configure LAPS settings вы в документации обновление сделаете? https://www.altlinux.org/Групповые_политики (Установка пароля для локального пользователя root Не реализовано) https://www.altlinux.org/Групповые_Политики/Установка_пароля_root
