openldap-devel

openldap-devel@openldap.org

1418 discussions

Re: cn=config: sharing, conditionals
by Raphaël Ouazana-Sustowski 29 May '09

29 May '09

Hi, Le Ven 29 mai 2009 16:11, Howard Chu a écrit : > Rein Tollevik wrote: >> Howard Chu wrote: >>> Howard Chu wrote: >>>> Since there is currently no support at all, I think it's important to >>>> get >>>> something usable first, and worry about those other cases later. >>> >>> The other alternative, which is much simpler to implement, is just to >>> add a suffixmassage/rewrite keyword to the syncrepl config, allowing it >>> to pull from a particular remote base and map it to the local base. >>> Then >>> it's up to the sysadmin to create a complete cn=config hierarchy >>> somewhere else on the master server and let the slaves pick it up. That >>> would address all of the issues of differentiation, at the cost of a >>> little bit of redundancy on the master. >> >> I'm not too fond of the proposed olcServerMatch, it appears to me to >> create a cluttered config database that requires you to match these >> attribute values to see the currently active configuration. Should it >> be added though, then I would prefer it to be defined as range(s) of >> serverIDs rather than a pattern to match. Regexp matching of integer >> ranges is always awkward.. > > Yes, I agree, it would make things cluttered and the complexity could > easily > get out of hand. In retrospect I'm not so fond of the idea. Wouldn't it be possible to simply extend the attribute name to make it match a server? Eg: olcAccess;server1: ... olcAccess;server2: ... That would be IMHO more clear than any related regexp-attribute. Regards, Raphaël Ouazana.

2 1

Invalid DN after schema change
by Michael Ströder 29 May '09

29 May '09

HI! If one plays around with schema and an attribute type used in the RDN of an entry is no longer present then this entry is no longer readable because whenever a request is sent to slapd invalidDNSyntax is returned. This leads to the situation that a client can't even explicitly delete this offending entry anymore. I'd vote for relaxing the schema-based DN checking in case of search, rename (only old DN), modify and delete requests a bit so that after a schema change the data can be corrected with normal client tools without server down-time. Any thoughts on this? Ciao, Michael.

3 6

NUMA-aware tcmalloc
by Howard Chu 23 May '09

23 May '09

For those of you running multi-socket Opteron servers (and eventually, multi-socket Nehalem servers), AMD published a whitepaper last week on their work adapting Google's tcmalloc to be NUMA-aware. The whitepaper includes links to their source code / diffs. It appears to be quite a performance boost in their (very artificial) benchmark. I'll be trying it out soon myself. -- -- 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

current RE24 experience
by Aaron Richton 14 May '09

14 May '09

I've had a spurt of bad luck with 2.4.16 (it appears Quanah and a few others may share that opinion). The seg faults inspired me to run under libumem, which has some interesting features that give you "moderate" debug ability in exchange for moderate performance hit -- small enough that I can run it hot safely, unlike full-featured memory debuggers. At this point a RE24 checkout from late Saturday has been good for me in production, with some moderate libumem checks enabled. Is everybody else starting to see RE24 shape up? Bottom line...I think I'm now +1 for encouraging a 2.4.17 train, for what it's worth...

4 6

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

ITS#4829, creating olcDbDirectory
by Howard Chu 30 Apr '09

30 Apr '09

I thought I had a good idea for this, although upon further reflection it still has holes. But it may still be a good starting point for discussion: For backends that support the olcDbDirectory keyword, we should also define a write-only olcDbMkdir attribute. If it's provided when ldapadd'ing an olcDatabase entry, or when ldapmodifying, then its values are treated as pathnames that we will attempt to create before processing any other parts of the request. This attribute would not be persisted in the cn=config backing store, so it will only take effect on dynamic operations, not when reloading the config on a subsequent startup. If the target directory already exists and is owned by the current uid, then it's a no-op. If the owner doesn't match, or the target pathname is not a directory, the request will fail. Otherwise, we try the mkdirs and proceed if they succeed. No cleanup will be performed on a failure - it would be pretty rude to "rm -rf" an existing database here. It may still be worthwhile to provide a global setting defining the filesystem locations that are allowed to be used. (Of course, anyone with back-config's rootdn credentials can set it to anything they want, anyway.) Comments? -- -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel