Cas pratiques

Conseils généraux

Les expressions régulières doivent être utilisées uniquement quand cela est nécessaire. Quand on veut mettre en objet un sous arbre, on préférera utiliser le dnstyle one sub ou children en fonction du besoin.

Par ailleurs, pour éviter toute ambiguïté, il est préférable de toujours préciser les style et dnstyle plutôt que de s'appuyer sur les valeurs par défaut. Si vous connaissez par coeur toutes les style et dnstyle implicite, ce n'est pas forcément le cas de la personne qui relira le fichier de configuration après vous.

Le composant d'expression régulière (.)* est à éviter, parce qu'il peut correspondre à beaucoup trop de chose, y compris une chaîne vide. On lui préférera le composante (.)+, qui correspond à une chaîne d'au moins un caractère. On peut aussi parfois utiliser le composant [^,]+ qui correspond à une chaîne d'un au moins un caractère et ne contenant pas de ,, ce qui permet d'isoler un niveau dans un DN.

De même l'on pensera à encadrer les expressions régulière d'un ^ et d'un $. Le premier correspond à un début de chaîne, le second à une fin de chaîne. Cela permet d'être certain que l'expression régulière ne répond pas à une surchaîne.

Exemple 7.7. Le piège des surchaînes

L'expression régulière

cn=[^,]+,ou=admin,dc=ee,dc=fr

répondra positivement au DN

cn=niakniak,ou=admin,dc=ee,dc=fr,cn=cracker,ou=users,dc=ee,dc=fr

Pour éviter ce détournement, il faut utiliser l'expression régulière suivante:

^cn=[^,]+,ou=admin,dc=ee,dc=fr$

, ou encore

^cn=([:alnum:]+),ou=admin,dc=ee,dc=fr$

À la fin du parcours de toutes les clauses, slapd affecte une permission par défaut. Cette permission par défaut est définie dans le fichier de configuration du serveur. Or la clause qui permet de définir ces permissions par défaut est devenu dépréciée dans la version 2.1. Cela signifie qu'elle sera supprimée des prochaines versions du logiciel. Il faut donc commencer à s'en passer et remplacer son usage par une clause de permission finale.

Permission pour la création d'enfants

La clause:

    access to dn.children="ou=contacts,dc=ee,dc=fr" 
            by dn="cn=intreenet,ou=apps-accounts,dc=ee,dc=fr" write 

n'autorise pas la création d'enfants sous le noeud ou=contacts,dc=ee,dc=fr. Cette clause permet l'accès en écriture aux noeuds enfants, mais pour pouvoir créer des enfants, il faut rajouter une clause permettant de modifier aussi l'entrée ou=contacts,dc=ee,dc=fr.

La clause:

    access to dn="ou=contacts,dc=ee,dc=fr" attrs=children
            by dn="cn=intreenet,ou=apps-accounts,dc=ee,dc=fr" write 

donne bien l'autorisation voulue, le droit d'écriture sur l'entrée ou=contacts,dc=ee,dc=fr, pour créer des enfants sous le noeud.

Les deux clauses sont donc nécessaires.

Restriction pour la création d'enfant

Nous souhaitons maintenant permettre à un utilisateur donné (en réalité à une application) de créer, modifier et supprimer, mais uniquement des utilisateurs d'un type particulier (l'objectclass est fixé). Il faut modifier notre première clause pour y ajouter le filtre:

    access to dn.children="ou=contacts,dc=ee,dc=fr" 
        filter=(objectclass=eeintreenetobject)
            by dn="cn=intreenet,ou=apps-accounts,dc=ee,dc=fr" write 
            by users read
            by * break