changed notes changed state Open to Closed
Full_Name: Ace SU-ares Version: 2.1.22 OS: Linux ? URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.152.170.243) when using group.regex in the 'by' clause of an ACL, the argument to group.regex may NOT be a regular expression (regex). If the argument is a regex, the by clause will be dropped without an error (i.e. when reading the configuration file, no errors are triggered, and when using the clause while looking up access, it is silently dropped with no trace in the logfiles (with spald -d 128) However, replacements may be used. If the 'to' clause containes parenthesized regular expressions that are matched, they can be referenced in group.regex with $1, $2 etc. Example (WRONG) access to dn.regex="cn=(.+),ou=people" by group.regex="manager=.*,ou=people" write --> the by clause will be silently dropped during access_allowed evaluation Example (RIGHT) access to dn.regex="cn=(.+),ou=people" by group.regex="manager=$1,ou=people" write --> altough a Silly Example(TM), the regex will evaluate properly. It is suggested by Kurt Zeilenga during mailing list discussion that this needed to be fixed in documentation. However, I would suggest that this would be fixed in code and that groupr.regex will take any proper regex. Note that 'group' without 'regex' will default to regex, adding to the confusion. _Ace
At 05:49 PM 10/22/2003, ace@suares.nl wrote: >Full_Name: Ace SU-ares >Version: 2.1.22 >OS: Linux ? >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (216.152.170.243) > > >when using group.regex in the 'by' clause of an ACL, the argument to group.regex may NOT be a regular expression (regex). As noted on the software list, group.regex takes a replacement string where replacements are made based upon a previously evaluated regular name. The document in HEAD (and, IIRC, 2.2) has been clarified. >If the argument is a regex, the by >clause will be dropped without an error (i.e. when reading the configuration >file, no errors are triggered, and when using the clause while looking up >access, it is silently dropped with no trace in the logfiles (with spald -d >128) Most skipping of by clauses is not logged. You're welcomed to submit a patch to provide more logging. >It is suggested by Kurt Zeilenga during mailing list discussion that this needed to be fixed in documentation. However, I would suggest that this would be fixed in code and that groupr.regex will take any proper regex. The code is not considered broken. It's not a regex, it's a replacement string. I personally don't think it makes sense to support a regex here as there is no reasonable string known to be associated with the subject to be the target of the regex. Hence, I'm inclined to reject your request. Kurt
Dear Kurt, Thank you for your prompt reply on this ITS that I only submitted few hours ago. I really appreciate that. > As noted on the software list, group.regex takes a replacement > string where replacements are made based upon a previously > evaluated regular name. The document in HEAD (and, IIRC, 2.2) > has been clarified. Good. > > >If the argument is a regex, the by > >clause will be dropped without an error (i.e. when reading the > > configuration file, no errors are triggered, and when using the clause > > while looking up access, it is silently dropped with no trace in the > > logfiles (with spald -d 128) > > Most skipping of by clauses is not logged. You're welcomed to > submit a patch to provide more logging. If I could do that I wouldn't write an ITS but submit a patch. Not everybody is a C programmer. I do hope I can make other contributions to OpenLDAP though, as the software is vary valuable from me since 1999 or so when I started using qmail-ldap. > > I personally don't think it makes sense to support a regex here > as there is no reasonable string known to be associated with the > subject to be the target of the regex. Pesronally, I had the following in mind: access to somedn by group.regex="qGroup=.*,qDomain=suares.an,qApp=qwido" this would give access to all members of all groups under qDomain=suares.an and this is a serious consideration on my side, since groups can have members that come from anyplace inside the tree, so a simple regex for all members of all groups could not exist. > > Hence, I'm inclined to reject your request. > > Kurt I am thus inclined to disagree with your inclination to reject this request. _Ace -- website: http://www.suares.nl * http://www.qwikzite.nl
At 08:10 PM 10/22/2003, ace@suares.nl wrote: >> >If the argument is a regex, the by >> >clause will be dropped without an error (i.e. when reading the >> > configuration file, no errors are triggered, and when using the clause >> > while looking up access, it is silently dropped with no trace in the >> > logfiles (with spald -d 128) >> >> Most skipping of by clauses is not logged. You're welcomed to >> submit a patch to provide more logging. > >If I could do that I wouldn't write an ITS but submit a patch. I suspect you could write the code if you put your mind to it. Adding additional logging isn't rocket science. >> I personally don't think it makes sense to support a regex here >> as there is no reasonable string known to be associated with the >> subject to be the target of the regex. > >Pesronally, I had the following in mind: > >access to somedn > by group.regex="qGroup=.*,qDomain=suares.an,qApp=qwido" > >this would give access to all members of all groups under qDomain=suares.an >and this is a serious consideration on my side, since groups can have members >that come from anyplace inside the tree, so a simple regex for all members of >all groups could not exist. That's not feasible. Aside from the difficulties in determining all the group DNs which the regex might match, the server would have to evaluate the regex against each of these group DNs to see if it matched. That would be quite expensive even where the set was small. I continue to be inclined to reject this request. Kurt
> At 08:10 PM 10/22/2003, ace@suares.nl wrote: > >> >If the argument is a regex, the by > >> >clause will be dropped without an error (i.e. when reading the > >> > configuration file, no errors are triggered, and when using the clause > >> > while looking up access, it is silently dropped with no trace in the > >> > logfiles (with spald -d 128) > >> > >> Most skipping of by clauses is not logged. You're welcomed to > >> submit a patch to provide more logging. > > > >If I could do that I wouldn't write an ITS but submit a patch. > > I suspect you could write the code if you put your mind to it. Adding > additional logging isn't rocket science. I apply rocket science to devise a openldap based virtual isp management system, in PHP. Is that okay with you ? It'll have nifty things like spawning new usermode linux virtual servers (like a qmail-ldap server in usermode linux) by entering just an ipaddress and the qService attribute set to qmail-ldap. Is that good enough ;-) Honestly. I have enough to put my mind into at the moment. ACL's have been a struggle, and I plan on writing documentation for it. But before I will write documentation on it, I need a ldap-based document review system (aptly named qwitext and based on freetext (www.drostan.org). It's in these areas (ACL documentation, and using openLDAP to base software that can be usefull upon) that I could help openldap's progress. It's in *not* in C. I also run an ISP for a living (which enables me to have 'free time' to do development) and am working on bringing Linux (LTSP) into schools here in Curacao. I appreciate your work and I can understand the more C coders join, the better. But it's not on my todo-list - yet. > > >> I personally don't think it makes sense to support a regex here > >> as there is no reasonable string known to be associated with the > >> subject to be the target of the regex. > > > >Pesronally, I had the following in mind: > > > >access to somedn > > by group.regex="qGroup=.*,qDomain=suares.an,qApp=qwido" > > > >this would give access to all members of all groups under > > qDomain=suares.an and this is a serious consideration on my side, since > > groups can have members that come from anyplace inside the tree, so a > > simple regex for all members of all groups could not exist. > > That's not feasible. Aside from the difficulties in determining all the > group DNs which the regex might match, the server would have to evaluate > the regex against each of these group DNs to see if it matched. That would > be quite expensive even where the set was small. Hmm... when I went to sleep last night I had similar thoughts. dn.regex has as input ONE dn, and just checks if it matches. group.regex needed to do something like: - compile a list of all DN's in the entire tree that match the group.regex - then collate all DN's of all members of these groups - then lookup the autenticated_dn in that list. I see that that would be very expensive. And it's 'the other way around' from how dn.regex works - I didn't see that when I wrote my answer yesterday. Let alone if another group where a member of one of the groups. (Which reminds me that I should test how that works in 2.1.22, probably no recursion happening there, especially for avoiding loops.) > I continue to be inclined to reject this request. I agree with the continuation of your inclination to reject the request (and withdraw the request if needed). Cheers, ace PS I'll submit another ITS about the comments in the ACL list - don't be angry with me. > > Kurt -- Ace Suares' Internet Consultancy NIEUW ADRES: Postbus 2599, 4800 CN Breda telefoon: 06-244 33 608 fax en voicemail: 0848-707 705 website: http://www.suares.nl * http://www.qwikzite.nl
moved from Incoming to Archive.Incoming
rejected as being infeasible to implement