How atomic are changes made to database entries with the following type of LDIFs:
dn: olcDatabase={1}bdb,cn=config changetype: modify add: olcAccess olcAccess: {100}to <what> by <who> read olcAccess: {65000}to <what> by <who> none
Does ldapmodify simply add/remove attributes on the fly, or does it get the whole entry, then update a new one in? This may become significant if there are a large number of ACLs. If the update is not atomic, is there a potential for problems if the list of ACLs becomes large (ie: 200 <whats> with an average of 10 <whos> each) ?
Background: The aim here is to leverage nss_ldap and olcAccess entries to manage access to servers while maintaining control of which accounts appear on which servers via OpenLDAP, rather than filters on the client side. This is to prevent servers that have been misconfigured or (maliciously) modified from being able to gain read access to user entries other than the ones explicitly allowed by the directory. IMO, a client server being able to pick who should be allowed to log on defeats the purpose of centrally managed logins.
Romain Komorn
explicitly allowed by the directory. IMO, a client server being able to pick who should be allowed to log on defeats the purpose of centrally managed logins.
The principle of least access is a good one, and it's certainly valid to make sure that servers don't see more than they need to. But be wary of this influencing an ability to "pick who should be allowed." I'd claim that anybody that controls a server to the point where which entries are shown by the LDAP server are the effective limiting factor controls that server to the point where server-side vs. client-side filtering is the least of your worries.
To put it another way: Filtering '(memberOf=magicRootPeople)' on client:/etc/ldap.conf, or filtering '(memberOf=magicRootPeople)' with an OpenLDAP ACL, is utterly irrelevant when somebody can ed /etc/nsswitch.conf and change it to "files."
Of course there's something to be said for onion layers and all that, and restricting visibility can be desirable for numerous reasons. But stopping you from
...viewing certain entries is something that needs to be carefully considered with other elements; don't use it alone.
Romain Komorn wrote:
How atomic are changes made to database entries with the following type of LDIFs:
dn: olcDatabase={1}bdb,cn=config changetype: modify add: olcAccess olcAccess: {100}to <what> by <who> read olcAccess: {65000}to <what> by <who> none
Does ldapmodify simply add/remove attributes on the fly, or does it get the whole entry, then update a new one in? This may become significant if there are a large number of ACLs. If the update is not atomic, is there a potential for problems if the list of ACLs becomes large (ie: 200 <whats> with an average of 10 <whos> each) ?
By definition, all updates in LDAP are atomic.
Background: The aim here is to leverage nss_ldap and olcAccess entries to manage access to servers while maintaining control of which accounts appear on which servers via OpenLDAP, rather than filters on the client side. This is to prevent servers that have been misconfigured or (maliciously) modified from being able to gain read access to user entries other than the ones explicitly allowed by the directory. IMO, a client server being able to pick who should be allowed to log on defeats the purpose of centrally managed logins.
Agreed, nss_ldap is a broken design.
openldap-software@openldap.org
-
Aaron Richton -
Howard Chu -
Romain Komorn