Conjuntos de uso do OpenLDAP ACL

Question

Então, estou tentando escrever algumas regras LDAP que permitirão a certas pessoas a capacidade de escrever algumas subárvores.

Digamos que temos esse usuário:

dn: uid=minion1,o=mycompany,ou=cust,dc=some,dc=domain
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
isAdmin: TRUE

E este usuário:

dn: uid=minion2,o=mycompany,ou=cust,dc=some,dc=domain
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
isAdmin: FALSE

Ah, e esse usuário:

dn: uid=minion3,o=notmycompany,ou=cust,dc=some,dc=domain
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
isAdmin: FALSE

Estou tentando definir permissões para minion1 para modificar a conta de minion2, mas não minion3 (se você observar, minion3 está em uma organização diferente "notmycompany", onde as outras duas estão em "mycompany").

A regra básica é que um usuário deve ter a capacidade de adicionar / modificar / excluir entradas em sua organização com base em se a propriedade "isAdmin" estiver definida como TRUE, E se o objeto estiver na mesma organização que o usuário ele / ela deseja modificar.

Minha ACL funcionando parcialmente é:

to dn.regex="^.+o=([^,]+),ou=cust,dc=some,dc=domain$" 
by set="user/isAdmin & [TRUE]" write 

Isso, é claro, permitirá que eles modifiquem a conta do minion3 também. Eu gostaria de adicionar

"[^.+,o=$1,ou=cust,dc=some,dc=domain$]"

para a linha acima, mas até agora eu falhei miseravelmente. Alguém tem alguma boa ideia que eu possa tentar? (Eu expliquei o que estou tentando fazer aqui adequadamente)?

Agradecemos antecipadamente;

    

Answer 1

Passei algum tempo pesquisando a documentação sobre conjuntos e o problema que você Os operadores de set (como & ) realmente funcionam apenas com dados do mesmo tipo ... assim, você pode pedir a interseção de um DN e um DN, ou um valor de atributo e uma string, mas interseções de coisas de diferentes tipos não fazem sentido.

Então, criamos uma string usando o atributo isAdmin e as maravilhas da concatenação de strings, assim:

olcAccess: {1}to dn.regex="o=([^,]+),ou=cust,dc=some,dc=domain$" 
    by set.expand="([admin=] + user/isAdmin + [,] + user/-1) & ([admin=TRUE] + [,o=$1,ou=cust,dc=some,dc=domain])" write 
    by * break

Observe o usuário de set.expand , porque queremos usar $1 na definição do conjunto e observe o uso de [...] para colocar valores literais nas sequências que estamos avaliando.

Para alguém conectado como minion1 , isso solicitará a interseção de:

admin=TRUE,o=mycompany,ou=cust,dc=some,dc=domain

e o valor literal:

admin=TRUE,o=mycompany,ou=cust,dc=some,dc=domain

Qual é um conjunto não vazio, então funciona. Para alguém com isAdmin=FALSE (ou nenhum atributo isAdmin ), a comparação seria com admin=FALSE,... ou admin=,... . Da mesma forma, para alguém que não esteja na mesma organização o=... do destino, a interseção produzirá um conjunto vazio.

Se você estiver interessado, isso é o que eu realmente usei para testar. Eu estou usando employeeType em vez de isAdmin porque eu não queria mexer com a adição de um novo atributo ao meu esquema.

Além disso, slapd -dacl ... é seu amigo.