[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#4218) back-config broken in HEAD



ando@sys-net.it wrote:
> On Sat, 2005-11-26 at 00:28 +0100, Pierangelo Masarati wrote:
>   
>> This patch makes it work again, but it's a horrible hack; I couldn't
>> find a better place to hijack the rootdn when it changes.
>>     
>
> Sigh, this fixes the rootDSE issue (which was just a symptom that all
> entries after "olcDatabase={0}config,cn=config" could not be opened
> because of insufficient access), but then anything trying to access
> "cn=replica-config" results in a SIGSEGV, I think because all the suffix
> massage info didn't make into the config database.  It's not going to be
> anything quick to parse/unparse/... all that stuff.

Right, basically back-relay is unsupported here.

re: the hack - I was looking at this overlay_access code and I'd much 
prefer a different solution. Part of the problem is that the op->o_bd is 
being set to frontendDB to invoke things from the global perspective, on 
the assumption that the current o_bd can be recovered again via 
select_backend(). Unfortunately that assumption is False for many of the 
overlays as well as for back-config. Besides which, this results in far 
too many extra calls to select_backend over the course of a single 
operation.

The frontend access() function should be called directly, not through 
the frontendDB pointer. It should just know if it needs to invoke an 
overlay (by virtue of the SLAP_DBFLAG_GLOBAL_OVERLAY flag) and then 
invoke the overlay structure as needed, otherwise fallthrough to its 
normal processing, without disturbing the current op->o_bd pointer.

I'm a bit skeptical about what a global ACL overlay can do, without 
knowledge of the underlying real DB... Again, since we know we're 
working from the global perspective, we should just access 
frontendDB->bd_info directly without modifying op->o_bd. (Aside from 
dup'ing it into a local copy.) So basically over_access_allowed and 
fe_op_acl need to merge together. Similar fixes are probably needed for 
_acl_group and _acl_attribute, I haven't looked that far.

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/