Enforce A Consistent Access Control List...

  • Автор темы Автор темы lmike
  • Дата начала Дата начала

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
8 005
611
нотусня 7.0.3
ситуация несколько искусственная, но пришлось столкнуться
Есть комп на кот. используется локальная реплика, и всё бы ничего, если бы не несколько юзеров (и соответ. ИД файлов) на этом писюке. Установка единым каталогом (дата не разнесёе по юзерам) и пользователь винды - один
если я создам реплику, с выставленной галкой, под одним из юзеров - то группы будут работать, но только для этого юзера
т.к. юзеров немного, выход - прописать их в АКЛ, и не юзать группы в редерс/авторс полях
но хотельось бы знать - это принципиальная фича нотусни или с новыми релизами будт править/ уже исправили?
 
а эти группы в локальной АК вообще есть? ;)
 
"Enforce" заставляет сохранять права пользователя, создавшего реплику в самой реплике, для дальнейшей проверки прав по ACL. Но это только для создавшего реплику пользователя. Другие не авторизуются, т.к. для этого требуется сохранять локально весь состав групп. Т.е. это принципиальная фича. Ворэраунд -- явное указание в ACL, либо многопользовательская установка. Во втором случае реплика должна создаваться под правами конечного пользователя. Ну, ты это и сам знаешь.


Группы локальной АК учитываются если не установлен "Enforce"
 
TIA спасибо, я надеялся, что сделают/лали фичу - типа дополнение прав, для каждого вновь реплицирующего с сервера (на уровне галочки в реплике)
 
Но это только для создавшего реплику пользователя. Другие не авторизуются, т.к. для этого требуется сохранять локально весь состав групп
Откуда данные? Не исследовал специально, но, мне показалось, что нотес кеширует данные о пользователе у себя, а на уровне реплики ничего подобного не хранит.
 
а на уровне реплики ничего подобного не хранит.
легко проверить ;)
ставишь галку и включаешь юзеров в группу (АК на сервере)
в АКЛ:
-прописываешь группу! с авторс доступом
-дефолту - Но-Аксец
создаешь локальную реплику, под одним ИД, переключаешь ИД и пробуешь открыть базу (получишь облом)
Причем, базу можешь перенести на др. комп, с нотуснёй и попробовать открыть под разными ИД (тока по ИД, кот. создал - будет открываться)
 
легко проверить
Ну, все же документальное подтверждение от ибэма, если имеется, было бы интересно увидеть. А тесты это хорошо, но не всегда удается получить полную достоверную информацию. Вот ;)

Хотя, возможно так и есть, и доступ все же хранится в реплике. Вспомнил, что на днях открывал реплику одной БД, взятой с сервера. Так она локально не хотела открываться, несмотря на то, что пользователь был в группе, которая прописана в ТУД (блин, мужики, эти транслитерированые термины, что вы используете, как-то не воспринимаются совсем), и клиент имел связь с сервером имен.
 
на днях открывал реплику одной БД, взятой с сервера. Так она локально не хотела открываться, несмотря на то, что пользователь был в группе, которая прописана в ТУД
А реплика не шифрованная была?
 
Не, серверная. Пользователь, прописанный явно, без проблем получил доступ.
 
>Ну, все же документальное подтверждение от ибэма, если имеется, было бы интересно увидеть. А тесты это хорошо, но не всегда удается получить полную достоверную информацию.
достаточное подтверждение? ;)

When a database is replicated locally, information about the group membership of the person doing the replication is stored in the database for use in ACL checking. If a person/identity other than the one doing the replication accesses the local replica, there will be no group membership information available for that person, and the ACL can use only the person's identity, not group membership, to check access.
 
Мы в соцсетях:

Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab