Управляемая публичность данных

[vk]

Здравствуйте!
ЛДАП настроен так, что у простых пользователей нельзя прочитать многие атрибуты (например, sn)
Есть категория пользователей, которым данные реквизиты нужно открыть.

Вопрос состоит в следующем - как написать правило доступа "у определенных пользователей атрибут sn могут читать все"?

Что-то типа
access to group="cn=PublicPeople,dc=example,dc=com" attrs=sn
by * read

Т.е. у группы PublicPeople есть атрибут member, и у всех, кто упомянут в member, можно было прочитать sn

[egor]

Здравствуйте!
На "чистой" БД стандартными ACL выполнить такой финт не получится. Но если использовать наложение memberof, то можно уже кое-что придумать:

Код: [Выделить]

access to filter=(memberof=cn=PublicPeople,dc=example,dc=com) attrs=sn
    by * read
access to attrs=sn
    by * none
access to *
    by * read
Кажется, то, что Вы хотели.

Егор

[vk]

Да, похоже это именно то, что нужно!
Правда придется подключать дополнительное наложение...
Спасибо большое, попробую.

П.С. не подскажите еще, как настроить фильтр, если заранее dn группы неизвестен?
Например - есть подразделения
ou=a,dc=example,dc=com
ou=b,dc=example,dc=com
..
ou=z,dc=example,dc=com
в каждом из них есть "контактные лица", перечисленные в
cn=PublicPeople,ou=a,dc=example,dc=com
cn=PublicPeople,ou=b,dc=example,dc=com
..
cn=PublicPeople,ou=z,dc=example,dc=com

Как лучше указать правило в таком случае?

[egor]

Здравствуйте! Гибкость ACL в OpenLDAP имеет свои пределы =) . Отобрать записи в условии <what> директивы access to можно либо по поддереву (dn), либо по фильтру (filter). Как Вы понимаете, по поддереву в данном случае отбирать бессмыслено, поэтому и пришлось вводить наложение memberof и применять такой фильтр. Проблема в том, что у атрибута memberOf нет правила соответствия SUBSTR, то есть построить фильтр типа (memberOf=cn=PublicPeople,*) не получится, а следовательно одним красивым ACL Вашу задачу не решить.

Но это не значит, что задача не решается в принципе =) . Можно попытаться решить её "в лоб" фильтром типа (|(memberOf=cn=PublicPeople,ou=a,dc=example,dc=com)(memberOf=cn=PublicPeople,ou=b,dc=example,dc=com)(memberOf=cn=PublicPeople,ou=z,dc=example,dc=com)) , надеюсь, подразделений у Вас меньше, чем 16 =) , либо разделить такой ACL на несколько однотипных.

Егор

[vk]

Здравствуйте, Егор!

Можно попытаться решить её "в лоб" фильтром типа (|(memberOf=cn=PublicPeople,ou=a,dc=example,dc=com)(memberOf=cn=PublicPeople,ou=b,dc=example,dc=com)(memberOf=cn=PublicPeople,ou=z,dc=example,dc=com)) , надеюсь, подразделений у Вас меньше, чем 16 =)

Подразделений у нас около пятидесяти =(

П.С. Регэксп тоже не получится?
П.П.С. Да, еще. Каждый пользователей имеет атрибут ou. Пробовал сделать конкатенацией строк что-то типа
to filter=(memberof="([cn=PublicPeople,ou=]+this/ou+[,dc=example,dc=com])") attrs=sn * read
Для наборов работает, а здесь нет.

[egor]

Здравствуйте!

П.С. Регэксп тоже не получится?

Регулярные выражения применяются к DN, к атрибутам применяется правило соответствия SUBSTR, о чём я писал выше.

П.П.С. Да, еще. Каждый пользователей имеет атрибут ou. Пробовал сделать конкатенацией строк что-то типа
to filter=(memberof="([cn=PublicPeople,ou=]+this/ou+[,dc=example,dc=com])") attrs=sn * read
Для наборов работает, а здесь нет.

Наборы (set), также как и группы (group), используются ТОЛЬКО в условии by <who> директивы access to.

Подразделений у нас около пятидесяти =(

Если не хотите перечислять 4 (50/16) ACL с такими ужасными фильтрами, есть 2 обходных пути:

• Сделать общую группу cn=PublicPeople,dc=example,dc=com и вносить туда членов из разных веток.
• Ввести какой-нибудь дополнительный атрибут (например, второе значение ou) в записях "публичных" людей с признаком "публичности" и использовать в ACL фильтр типа (ou=PublicPeople). В этом случае можно обойтись без наложения memberof.

Всё зависит от Вашей политики ведения каталога.

Егор

[vk]

Здравствуйте!
Блин, ничего путнего я так и не придумал. Ни один вариант не нравится.
Но что поделать, видимо придется делать костыль из перечисления всех подразделений.

Подскажите, сильно ли влияет количество ACL на быстродействие системы?
Просто у меня уже 16 строчек ACL, если к ним прибавится еще 4-6 - не сильно ли громоздко получится?

[egor]

Здравствуйте!

Подскажите, сильно ли влияет количество ACL на быстродействие системы?
Просто у меня уже 16 строчек ACL, если к ним прибавится еще 4-6 - не сильно ли громоздко получится?

Само собой, обработка ACL занимает определённое время, но, мне кажется, принципиальной разницы между 16-ю и 20-ю ACL нет. К тому же обработка прекращается на первом сработавшем ACL, так что продумайте и расположите их грамотно, чтобы избежать лишних проверок.

Егор