openldap-devel May 2009

openldap-devel@openldap.org

18 participants
15 discussions

Negated ACL fields?
by Rein Tollevik 11 May '09

11 May '09

I have some ACLs where the same <who> statements are included in all the <by> fields. Rather than re-evaluating them each time I would like to quickly skip the entire ACL by negating the statements. I.e, rather than: access to * by <who1> <who2> ... by <who1> <who3> ... I'd like to say: access to * by !<who1> break by <who2> ... by <who3> ... And, I would like to negate the individual <who> statements, not necessarily all of them. This would also immediately make it useful to include the same type of <who> statement more than once in a <by> field, i.e: access to * by !dn=something !dn=something-else ... Neither of these can be easily implemented with the current internal representation of the <who> statements, as each type is now an element in the Access struct that represents the entire <by> field. To do it this would have to be changed into a struct which includes a list of <who> statements, evaluated in the order they are defined. Making this change is likely to alter the order in which existing ACL <who> statements are evaluated, but their combined effect should be the same since they are effectively and'ed together. Unless evaluating any of them have other side-effects that is, which they don't have as far as I know. This would also give the administrator full control of the order in which the statements are evaluated, which I find to be a Good Thing. As of now relatively "cheap" statements like testing the security strength factors are evaluated after potential "costly" operations like set statements. If the <who> statements are to be changed like this it makes sense to do the same to the <what> fields as well. Which again raises the question as to how regexp captions should be handled. For negated fields it is meaningless to capture any regexp fields, so they should not define nor alter any already captured sub-matches. For the other I find it most natural that the last evaluated <what> field defines the sub-matches for that <what> type, and making the sub-matches immediately accessible in the <what> fields that follows them. Allowing <what> fields to be negated would also eliminate the need to define "artificial" objectclasses to allow negated "attrs" lists. I.e, assuming the "attrlistClass" objectclass allows "attr1" and "attr2", the following would be equivalent: access to attrs=@attrlistClass by ... access to !attrs=!attrlistClass by ... access to attrs=attr1,attr2 by ... as would: access to attrs=!attrlistClass by ... access to !attrs=@attrlistClass by ... access to !attrs=attr1,attr2 by ... Assuming the "sufficient" control discussed in my previous posting is also accepted I could quickly grant read access to all attributes in an entry, leaving the actual choice at to whether they can be read to the access granted to the entry itself, using the following (after other ACLs that protects any non-readable attributes): access to !attrs=entry,children by * read sufficient Attempting the same with write would be disastrous though, as write access to an attribute do not require write access to the "entry" pseudo attribute, whereas read access to the "entry" is required to read its attributes. Comments? -- Rein Tollevik Basefarm AS

1 0

ACL decisions based on requested access
by Rein Tollevik 11 May '09

11 May '09

I have a fairly complicated ACL set which I need to optimize the evaluation of. To do this I need to make decisions based on the requested access level, which currently isn't possible (as far as I know that is). E.g, most of my ACLs are concerned with whether the entries and attributes should be read or writable or not, and I would like to quickly grant search access when that is all that is requested. One possibility I have considered is to add a new optional <requested access> field between the existing <who> and the <access> clauses, but I'm not very happy with that solution as it could easily be mixed with the existing <access>. So far my preferred solution is to add two new ACL controls, which I currently think of as "sufficient" and "requested". The "sufficient" control should act like "stop" (i.e grant access) if the effective <access> is sufficient for the requested access level, "continue" otherwise. The "requested" control should act like "continue" if the effective <access> matches what is requested, "break" otherwise. I initially thought that "break" should be the non-match action in both controls, but I think "continue" is the best for "sufficient" as that allows further decisions to be made in the same ACL without repeating the <to> part in a following ACL. At the cost of repeating the <who> part in a new condition in the same ACL if "break" was really needed.. I.e, both choices have their ups and downs, and I can live with both. I also though that "stop" should be the non-match case for "requested" to make the controls more symmetric. But that removes the ability to make further decisions in the succeeding rules, which I find highly unsatisfactory. These controls would allow access rules like the following to quickly grant search access if that is all that is requested, while keep on processing for other access types: access to <what> by <who> =s sufficient by * break An access rule where the <who> clauses are only evaluated when write access is requested could be written like: access to <what> by * =w requested by <who> =w Comments? It should be fairly easy to implement these controls, and I'll volunteer to do it if they are acceptable. -- Rein Tollevik Basefarm AS

4 4

configurable keepalive setting through libldap?
by Ralf Haferkamp 07 May '09

07 May '09

Hi, since quite some time libldap enables tcp-keepalive, e.g. to detected dangling syncrepl connections. However the default timeout of two hours that most systems are using might be a bit too long for some applications (e.g. I had a problem lately were nscd didn't answer queries anymore because nss_ldap was blocking in SSL_read() while the underlying connection has been cut off). On the other hand messing with the system wide settings might no be a good idea either. On Linux it is possible to configure the keepalive settings on a per socket basis through the TCP_KEEP* socket options. Would it be worth adding ldap_set_option() support for those, even if they are not really portable? -- regards, Ralf

5 9

Re: commit: ldap/contrib/slapd-modules/nssov README nssov.c nssov.h pam.c
by Howard Chu 04 May '09

04 May '09

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/contrib/slapd-modules/nssov > > Modified Files: > README 1.5 -> 1.6 > nssov.c 1.10 -> 1.11 > nssov.h 1.6 -> 1.7 > pam.c 1.7 -> 1.8 > > Log Message: > More for sessions, working. TODO: configure list of sessions to record For anyone interested, this is essentially code-complete. It works for me, but there are several areas I want to tweak still. Feedback on usability would be helpful at this point. If anyone wants to jump in and get a real manpage started, that would be nice too. The main objective here was to eliminate the libldap dependencies/clashes that the current pam_ldap/nss_ldap solutions all suffer from. A secondary objective was to allow for the possibility of more sophisticated caching than nscd provides. (E.g., run slapd back-ldap + pcache on each node.) Of course, you can also completey eliminate cache staleness considerations by running a regular database with syncrepl. And of course, another major objective was to allow all security policy to be administered centrally via LDAP, instead of having fragile rules scattered across multiple flat files. As such, there is no client-side configuration at all for the pam/nss stub libraries. (They talk to the server via a Unix domain socket whose path is hardcoded to /var/run/nslcd/). As a side benefit, this can finally eliminate the perpetual confusion over /etc/ldap.conf vs /etc/openldap/ldap.conf. User authentication is performed by internal simple Binds. User authorization leverages the slapd ACL engine, which offers much more power and flexibility than the simple group/hostname checks in the old pam_ldap code. At this point some cleanup is probably still needed, and merging the nslcd bits back into Arthur de Jong's code base is still underway. (Which means this code will be showing up in Debian soon, and I will be recommending it to the Ubuntu guys next month as well.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 3

Re: commit: ldap/libraries/liblber memory.c
by Howard Chu 01 May '09

01 May '09

hallvard(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/libraries/liblber > > Modified Files: > memory.c 1.74 -> 1.75 > > Log Message: > Fix previous fix: Don't #ifdef HAVE_STRNLEN before portable.h #defines that Since we're just talking about a simple for-loop, why are we even bothering to look for strnlen() at all? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel May 2009