ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | [FR] Групповые политики. Включить разрешение для запуска приложения любым пользователем, затем отменить разрешение -> Приложение доступно для запуска. Не очевиден эффект после применения состояния "политика Отключена" | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Branch p10 | Reporter: | Vera Blagoveschenskaya <vercha> | ||||||
| Component: | gpupdate | Assignee: | Valery Sinelnikov <greh> | ||||||
| Status: | NEW --- | QA Contact: | qa-p10 <qa-p10> | ||||||
| Severity: | normal | ||||||||
| Priority: | P5 | CC: | august, sa, shevchenkodyu, sin, sova, v.karpunin | ||||||
| Version: | не указана | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Attachments: |
|
||||||||
Еще исследования: - если выставить политику в Отключить и применить на клиенте. то поведение аналогичное, mtr разрешен для запуска доменному пользователю (в том числе и новому на этом клиенте!) - если ввести новую машину в домен, то политики отрабатывают корректно (mtr запустить нельзя), но ситуация повторяется, если еще раз включить-отключить разрешение Created attachment 9920 [details]
screen
Наткнулась на данную ошибку и в p10 # rpm -qa | grep gpupdate oddjob-gpupdate-0.2.0-alt1.x86_64 gpupdate-0.9.11.2-alt1.noarch alterator-gpupdate-1.3-alt1.x86_64 # rpm -qa | grep samba samba-dc-4.16.6-alt2.x86_64 admx-samba-4.16.6-alt2.noarch task-samba-dc-4.16.6-alt2.noarch samba-common-client-4.16.6-alt2.noarch samba-libs-4.16.6-alt2.x86_64 samba-dc-libs-4.16.6-alt2.x86_64 samba-winbind-4.16.6-alt2.x86_64 samba-dc-client-4.16.6-alt2.x86_64 samba-doc-4.16.6-alt2.noarch samba-pidl-4.16.6-alt2.noarch samba-4.16.6-alt2.x86_64 samba-winbind-common-4.16.6-alt2.x86_64 samba-common-4.16.6-alt2.noarch samba-dc-common-4.16.6-alt2.noarch samba-common-libs-4.16.6-alt2.x86_64 samba-client-4.16.6-alt2.x86_64 samba-common-tools-4.16.6-alt2.x86_64 python3-module-samba-4.16.6-alt2.x86_64 samba-winbind-clients-4.16.6-alt2.x86_64 Включение политик проверялось через gpui. Аналогично описанию, после удаления политики и перезагрузки, политика актуальна (проверялось на создании ярдыков на рабочем столе). Для нового пользователя на машине, уже введенной в домен - актуально. Политики не применяются только на новой машине, введенной в домен. Все еще актуально. Наткнулась при тестировании разрешения для postqueue Версии: gpui-0.2.34-alt1 gpupdate-0.9.12.6-alt1 (Ответ для Vera Blagoveschenskaya на комментарий #4) > Все еще актуально. > Наткнулась при тестировании разрешения для postqueue > > Версии: > gpui-0.2.34-alt1 > gpupdate-0.9.12.6-alt1 Вера, здравствуйте. Политика "Разрешение на использование /usr/bin/mtr" управляет утилитой control для mtr. ---- # control |grep mtr mtr netadmin (public netadmin restricted) ---- В политике присутствует выпадающий список, включающий в себя все 3 состояния. Если Вы ВКЛЮЧАЕТЕ политику, выставив одно из состояний, control перейдёт в заданное состояние. Если Вы переводите политику в состояние ОТКЛЮЧЕНО/НЕ СКОНФИГУРИРОВАНО, состояние самого control в системе никак не изменится, а останется именно таким, каким было до этого. Аналогично и для политики "Разрешения для /bin/su." Не вижу ошибки в данном случае. Политика гибко управляет контролом в зависимости от заданного состояния. Возможно, стоит добавить пояснения в сами admx шаблоны о таком поведении всех политик, связанных с control. (Ответ для Vera Blagoveschenskaya на комментарий #4) > Все еще актуально. > Наткнулась при тестировании разрешения для postqueue > > Версии: > gpui-0.2.34-alt1 > gpupdate-0.9.12.6-alt1 Вера, здравствуйте. Политика "Разрешение на использование /usr/bin/mtr" управляет утилитой control для mtr. ---- # control |grep mtr mtr netadmin (public netadmin restricted) ---- В политике присутствует выпадающий список, включающий в себя все 3 состояния. Если Вы ВКЛЮЧАЕТЕ политику, выставив одно из состояний, control перейдёт в заданное состояние. Если Вы переводите политику в состояние ОТКЛЮЧЕНО/НЕ СКОНФИГУРИРОВАНО, состояние самого control в системе никак не изменится, а останется именно таким, каким было до этого. Аналогично и для политики "Разрешения для /bin/su." Не вижу ошибки в данном случае. Политика гибко управляет контролом в зависимости от заданного состояния. Возможно, стоит добавить пояснения в сами admx шаблоны о таком поведении всех политик, связанных с control. (Ответ для SoVa на комментарий #6) > В политике присутствует выпадающий список, включающий в себя все 3 > состояния. Если Вы ВКЛЮЧАЕТЕ политику, выставив одно из состояний, control > перейдёт в заданное состояние. > Если Вы переводите политику в состояние ОТКЛЮЧЕНО/НЕ СКОНФИГУРИРОВАНО, > состояние самого control в системе никак не изменится, а останется именно > таким, каким было до этого. Аналогично и для политики "Разрешения для > /bin/su." Не вижу ошибки в данном случае. Политика гибко управляет контролом > в зависимости от заданного состояния. > Добрый день. Прошу сопровождающего пакета gpupdate прокомментировать ситуацию. На мой взгляд, состояние "Отключено" предполагает перевод того, что было включено, в обратное состояние. Также не понятно, чем в таком случае отличаются состояния "Отключено" и "Не сконфигурировано". > Возможно, стоит добавить пояснения в сами admx шаблоны о таком поведении > всех политик, связанных с control. Это значительно бы упростило понимание. (Ответ для Vera Blagoveschenskaya на комментарий #7) > (Ответ для SoVa на комментарий #6) > > В политике присутствует выпадающий список, включающий в себя все 3 > > состояния. Если Вы ВКЛЮЧАЕТЕ политику, выставив одно из состояний, control > > перейдёт в заданное состояние. > > Если Вы переводите политику в состояние ОТКЛЮЧЕНО/НЕ СКОНФИГУРИРОВАНО, > > состояние самого control в системе никак не изменится, а останется именно > > таким, каким было до этого. Аналогично и для политики "Разрешения для > > /bin/su." Не вижу ошибки в данном случае. Политика гибко управляет контролом > > в зависимости от заданного состояния. > > > > Добрый день. > > Прошу сопровождающего пакета gpupdate прокомментировать ситуацию. > На мой взгляд, состояние "Отключено" предполагает перевод того, что было > включено, в обратное состояние. > > Также не понятно, чем в таком случае отличаются состояния "Отключено" и "Не > сконфигурировано". > > > Возможно, стоит добавить пояснения в сами admx шаблоны о таком поведении > > всех политик, связанных с control. > > Это значительно бы упростило понимание. Добрый день. Я согласен с вами по поводу того, что состояние "Отключено" обычно ассоциируется с переходом из активного состояния в неактивное. Возможно, в данной ситуации это можно уточнить в документации или шаблонах admx, чтобы избежать путаницы. Предложение добавить пояснения к шаблонам звучит разумно и могло бы значительно облегчить понимание. (Ответ для Valery Sinelnikov на комментарий #8) > Добрый день. > > Я согласен с вами по поводу того, что состояние "Отключено" обычно > ассоциируется с переходом из активного состояния в неактивное. Возможно, в > данной ситуации это можно уточнить в документации или шаблонах admx, чтобы > избежать путаницы. Предложение добавить пояснения к шаблонам звучит разумно > и могло бы значительно облегчить понимание. Благодарю за пояснения. А что насчет двух вариантов состояний "ОТКЛЮЧЕНО/НЕ СКОНФИГУРИРОВАНО" с внешне "одинаковым" эффектом? "НЕ сконфигурировано" означает, что в файле Registry.pol отсутствует запись о политике. "Отключено" означает, что в файле Registry.pol запись о политике есть, но политика выключена. При перезагрузке компьютера происходит зачитывание этой по сути ненужной записи. Что , если оставить только два состояния: - Включено (с вариантами) - НЕ сконфигурировано ? Тогда вопросов от пользователей по функционалу ГП будет в разы меньше. Переквалифицирую данную задачу как Feature Request. |
Created attachment 9917 [details] gpupdate.log Конфигурация стендов: dc p9 server x86_64 dc2 p9 server x86_64 Клиенты: p9 education x86_64 / i596, p9 workstation x86_64 Win7 + RSAT # rpm -qa | grep gpupdate alterator-gpupdate-1.3-alt1.i586 oddjob-gpupdate-0.2.0-alt1.i586 gpupdate-0.9.2-alt1.noarch 1) На сервере установить пакет admx-basealt # apt-get install admx-basealt # samba-tool gpo admxload -U Administrator 2) На Windows машине зайти под администратором домена и подключиться к серверу через оснастку Управление групповой политикой: Панель управления - Администрирование - Управление групповой политикой. На имени домена ПКМ - Создать объект групповой политики Имя TestAltGPO 3) ПКМ на политике TestAltGPO - изменить. Конфигурация копьютера - Политики - Административные шаблоны - Система ALT. Изменить параметры нескольких политик Система ALT: Например, Безопасность - Разрешение для /bin/su: Включить - Любой пользователь может запускать /bin/su Сетевые приложения - Разрешение на использование /usr/bin/mtr: Включить - Любой пользователь 4) На клиенте выполнить команды # gpupdate # gpoa --loglevel 0 5) Под доменным пользователем и проверить изменения. Все применилось, запуск su и mtr возможен = ОК. 6) Отменить Разрешение на использование /usr/bin/mtr: Сетевые приложения - Разрешение на использование /usr/bin/mtr: Не задана 7) На клиенте выполнить команды # gpupdate # gpoa --loglevel 0 8) Перезагрузка клиента, вход пользователями: - тем же, что на шаге 5 - новым, свежесозданным Результат: запуск mtr возможен Аналогично, для другой политики, разрешение su- Ожидаемый результат: после шагов 6 и 7 запуск mtr обычным пользователем невозможен Дополнительно: ошибка найдена при тестировании версии gpupdate-0.9.8-alt1, но воспроизводится и на версии gpupdate-0.9.2-alt1