Full_Name: Peter Marschall Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-100411.patch Submission from: (NULL) (94.217.135.20) Hi, Playing around with dynacl/aci a bit I cam across the following issue: Searches that do not contain the attribute OpenLDAPaci in the list of attribues queried, omit objects. E.g. doing a base search for 1.1 on an object that has the following OpenDLAPaci value OpenLDAPaci: 0#entry#grant;r,c,s,d,x;[entry]#public# OpenLDAPaci: 0#entry#grant;r,c,s,d,x;[all]#public# (no superior object has a subtree OpenLDAPaci) does not return the DN of the object, while doing the search without arguments returns the DN. According to my experiments, it looks like the Entry *e passed as argument to dynacl_aci_mask() does not have OpenLDAPaci in its e->e_attrs. I wrote the patch ftp://ftp.openldap.org/incoming/Peter-Marschall-100411.patch to verify my suspicions, and it seems to help, although at the cost of abysmally bad performance. I guess there are better ways to fix the issue (e.g. "auto-adding" OpenLDAPaci to the attributes queried from the backend and stripping it before giving it back to the client), but my knowledge of the internal workings of OpenLDAP is too limited.
> Full_Name: Peter Marschall > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-100411.patch > Submission from: (NULL) (94.217.135.20) > > > Hi, > > Playing around with dynacl/aci a bit I cam across the following issue: > > Searches that do not contain the attribute OpenLDAPaci in the list of > attribues > queried, omit objects. dynacl/aci (as the original aci code it's based on) relies on the fact that the entry is complete. This is the case when the entry is stored locally, e.g. in back-bdb/hdb. Otherwise, no mechanism is in place to retrieve operational attributes. Please note that in the latter case, even ACL rules based on, say, createTimestamp or so would operate incorrectly. My guess is that you're trying to use ACIs with a non-local storage. In that case your analysis is correct. Can you provide your (sanitized) configuration? The "right" solution is much more general, not only related to dynacl. Slapd needs to know in advance what (operational) attributes are required for policy enforcing, and they need to be added to requested attrs when entries are collected from remote storage. Your patch seems to fix your specific need, but it is clearly inefficient. p.
>> Full_Name: Peter Marschall >> Version: 2.4.21 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-100411.patch >> Submission from: (NULL) (94.217.135.20) >> >> >> Hi, >> >> Playing around with dynacl/aci a bit I cam across the following issue: >> >> Searches that do not contain the attribute OpenLDAPaci in the list of >> attribues >> queried, omit objects. > > dynacl/aci (as the original aci code it's based on) relies on the fact > that the entry is complete. This is the case when the entry is stored > locally, e.g. in back-bdb/hdb. Otherwise, no mechanism is in place to > retrieve operational attributes. Please note that in the latter case, > even ACL rules based on, say, createTimestamp or so would operate > incorrectly. > > My guess is that you're trying to use ACIs with a non-local storage. In > that case your analysis is correct. Can you provide your (sanitized) > configuration? > > The "right" solution is much more general, not only related to dynacl. > Slapd needs to know in advance what (operational) attributes are required > for policy enforcing, and they need to be added to requested attrs when > entries are collected from remote storage. Your patch seems to fix your > specific need, but it is clearly inefficient. Automatically detecting what attributes need to be added to requests for proxying sounds like an overkill. Probably, a reasonable workaround could be to add a configuration directive that lists what attributes need to be added to requests. This directive should be honored by proxy backends and in general by all those backends that do not pass back complete entries to the frontend. In the case of proxy backends its use would be straightforward, since requested attrs need to be mapped anyway in the request. Adding some more would not be a big deal. Things might be a bit more complicated in case of, say, special configurations like proxycache, where ACIs would need to be added to all attribute templates, and so. Yet another reason to avoid ACIs :) p.
Thanks for your quick answer Pierangelo, On Monday, 12. April 2010, masarati@aero.polimi.it wrote: > > [...] > > My guess is that you're trying to use ACIs with a non-local storage. In > > that case your analysis is correct. Can you provide your (sanitized) > > configuration? I am using a local hdb backend. In order to generate a minimal test case I found out, that it seems to be related to the rwm overlay. Although I have set rwm-rewriteEngine to off, rwm seems to be partially active. Commenting out the rwm directives completely makes the searches work as expected. Please find attached a testcase with slapd.conf and ldif data. To experience the issue simply perform a search with e.g. attribute 1.1 as one of the users in the data. Then comment the rwm-... lines in slapd.conf, restart slapd and try again. Voilà the difference. > > [...] > > Automatically detecting what attributes need to be added to requests for > proxying sounds like an overkill. Probably, a reasonable workaround could > be to add a configuration directive that lists what attributes need to be > added to requests. This directive should be honored by proxy backends and > in general by all those backends that do not pass back complete entries to > the frontend. In the case of proxy backends its use would be > straightforward, since requested attrs need to be mapped anyway in the > request. Adding some more would not be a big deal. That would be absolutely sufficient for me. > Things might be a bit > more complicated in case of, say, special configurations like proxycache, > where ACIs would need to be added to all attribute templates, and so. Yet > another reason to avoid ACIs :) As much as I'd like to, but I fear I can't. I am trying to migrate from a non-OpenLDAP directory solution with a complex permission structure in in-tree ACLs to OpenLDAP. Unfortunately the permissions are set up in a way that do not let them write as a short list of ACLs. Changing the permission structure is not possible as lots of applications depend on it. -- Peter Marschall peter@adpm.de
changed notes changed state Open to Test moved from Incoming to Software Bugs
> --Boundary-00=_glFxL04kLcJl7l6 > Content-Type: Text/Plain; > charset="iso-8859-15" > Content-Transfer-Encoding: quoted-printable > > Thanks for your quick answer Pierangelo, > > On Monday, 12. April 2010, masarati@aero.polimi.it wrote: >> > [...] >> > My guess is that you're trying to use ACIs with a non-local storage. >> In >> > that case your analysis is correct. Can you provide your (sanitized) >> > configuration? > > I am using a local hdb backend. > > In order to generate a minimal test case I found out, that it seems to > be=20 > related to the rwm overlay. > > Although I have set rwm-rewriteEngine to off, rwm seems to be partially=20 > active. > Commenting out the rwm directives completely makes the searches work as=20 > expected. > > Please find attached a testcase with slapd.conf and ldif data. > To experience the issue simply perform a search with e.g. attribute 1.1 as > = > one=20 > of the users in the data. > Then comment the rwm-... lines in slapd.conf, restart slapd and try again. > Voil=E0 the difference. I see. probably, a relatively "quick" fix would be to allow to define a list of attributes, specific for a database, that is available to all implementations that need to muck with requested attrs (e.g. slapd-ldap, slapd-meta, slapo-rwm). They are supposed to be added to the list of requested attrs whenever appropriate. It's up to the administrato to keep it updated with everything that may be needed by special features like ACI. Something like required_attrs OpenLDAPACI In the future, we might be able to figure out a clever way to self-detect what attributes need to be treated this way. I'll work at that, time permitting. Thanks for reporting. p.
If you don't mind playing with HEAD code, you could try this patch <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-14-extra-attrs.1.patch> You need to add extra_attrs OpenLDAPACI within the database that contains the offending slapo-rwm instance. Please test and report. Thanks, p.
> If you don't mind playing with HEAD code, you could try this patch > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-14-extra-attrs.1.patch> Never mind, I think I already made it incompatible with HEAD code. I'm going to commit this stuff anyway, please stay tuned. p. > You need to add > > extra_attrs OpenLDAPACI > > within the database that contains the offending slapo-rwm instance. > > Please test and report. Thanks, p. > > > >
changed notes changed state Test to Release
changed notes changed state Release to Closed
fixed in HEAD fixed in RE24