Партнёры:
Хостинг:
The access control facility provided by the access directive is quite powerfull. This section shows some examples of it's use. First, some simple examples:
access to * by * read |
This access directive grants read access to everyone. If it appears alone it is the same as the following defaultaccess line.
defaultaccess read |
The following example shows the use of a regular expression to select the entries by DN in two access directives where ordering is significant.
access to dn=".*, o=U of M, c=US" by * search access to dn=".*, c=US" by * read |
Read access is granted to entries under the c=US subtree, except for those entries under the "o=U of M, c=US" subtree, to which search access is granted. No access is granted to c=US as neither access directive matches this DN.If the order of these access directives was reversed, the U-M-specific directive would never be matched, since all U-M entries are also c=US entries.
Note: every access to directive ends with an implicit by * none clause and every access list ends with an implicit access to * by * none directive. Only if no access controls are specified is the defaultaccess granted.
The next example again shows the importance of ordering, both of the access directives and the "by <who>" clauses. It also shows the use of an attribute selector to grant access to a specific attribute and various <who> selectors.
access to dn="(.*,)?o=U of M, c=US" attr=homePhone by self write by dn="(.*,)?o=U of M, c=US" search by domain=.*\.umich\.edu read access to dn="(.*,)?o=U of M, c=US" by self write by dn=".*, o=U of M, c=US" search by anonymous auth |
This example applies to entries in the "o=U of M, c=US" subtree. To all attributes except homePhone, the entry itself can write them, other U-M entries can search by them, anybody else has no access (implicit by * none) excepting for authentication/authorization (which is always done anonymously). The homePhone attribute is writable by the entry, searchable by other U-M entries, readable by clients connecting from somewhere in the umich.edu domain, and otherwise not readable (implicit by * none). All other access is denied by the implicit access to * by * none.
Sometimes it is usefull to permit a particular DN to add or remove itself from an attribute. For example, if you would like to create a group and allow people too add and remove only their own DN from the member attribute, you could accomplish it with an access directive like this:
access to attr=member,entry by dnattr=member selfwrite |
The dnattr <who> selector says that the access applies to entries listed in the member attribute. The selfwrite access selector says that such members can only add or delete their own DN from the attribute, not other values. The addition of the entry attribute is required because access to the entry is required to access any of the entry's attributes.
There's plenty of information about Access Control on the OpenLDAP Administrator's Guide. Take a look at: Access Control for more information about this subject.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |