Full_Name: Michael Str�der Version: HEAD OS: OpenSUSE Linux 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.119.62) HI! Just a feature request for convenience: Would it be possible to set the value of attribute 'modifiersName' to the DN of the overlays' configuration entry under cn=config if an entry was modified by an overlay? In this case one would have a direct link to the configuration if needed. Currently 'cn=<overlay name>' (e.g cn=Referential Integrity Overlay) is added which does not refer to an existing entry at all. Ciao, Michael.
> Just a feature request for convenience: > > Would it be possible to set the value of attribute 'modifiersName' to the > DN of > the overlays' configuration entry under cn=config if an entry was modified > by an > overlay? In this case one would have a direct link to the configuration if > needed. Currently 'cn=<overlay name>' (e.g cn=Referential Integrity > Overlay) is > added which does not refer to an existing entry at all. Technically, I don't see any problem, except that overlays (and software modules, in general) do not hold a direct reference to their config entry's DN, if any (e.g. when back-config is not in use, the data structure is in place, but not in LDIF form; please correct me if I'm wrong). I wonder whether exposing such detail makes sense, or risks breaking any security. Probably I'm getting paranoid... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
changed notes changed state Open to Test moved from Incoming to Software Enhancements
ando@sys-net.it wrote: >> Just a feature request for convenience: >> >> Would it be possible to set the value of attribute 'modifiersName' to the >> DN of >> the overlays' configuration entry under cn=config if an entry was modified >> by an >> overlay? In this case one would have a direct link to the configuration if >> needed. Currently 'cn=<overlay name>' (e.g cn=Referential Integrity >> Overlay) is >> added which does not refer to an existing entry at all. > > Technically, I don't see any problem, except that overlays (and software > modules, in general) do not hold a direct reference to their config > entry's DN, if any (e.g. when back-config is not in use, the data > structure is in place, but not in LDIF form; please correct me if I'm > wrong). I wonder whether exposing such detail makes sense, or risks > breaking any security. Probably I'm getting paranoid... As a quick fix to your legitimate issue, I've added to HEAD the refint_modifiersname parameter that allows to customize the name used for internal modifications. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
changed notes
moved from Software Enhancements to Development
changed state Test to Closed
changed state Closed to Test
The BackendDB structure could have a specific bd_modifiersName field for internal modifications; the slap_overinst structure could have a on_modifiersName as well. Both could be configurable using a(n optional, single-valued) olcModifiersName attribute. Internal writes would receive the modifiersName from: - the application; or - the overlay's olcModifiersName; or - the database's olcModifiersName; or - the database's rootdn; or - ?!? fail? remain anonymous? a call to int slap_get_modifiersName( Operation *op, BackendDB *be, slap_overinst *on, struct berval *mn, struct berval *nmn ) { *mn = op->o_dn; *nmn = op->o_ndn; if ( BER_BVISEMPTY( nmn ) ) { if ( on && !BER_BVISNULL( &on->on_modifiersName ) ) { *mn = on->on_modifiersName; *nmn = on->on_nmodifiersName; } else if ( be ) { if ( !BER_BVISNULL( &be->bd_modifiersName ) ) { *mn = be->bd_modifiersName; *nmn = be->bd_nmodifiersName; } else if ( !BER_BVISNULL( &be->bd_rootdn ) ) { *mn = be->bd_rootdn; *nmn = be->bd_rootndn; } } } return !BER_BVISEMPTY( nm ); } would return the appropriate value, if any. Probably a bit too much effort, but then multiple customizations that need to perform internal writes would be saved the effort and the dispersion of having to define their own configuration bit for a common feature. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
changed state Test to Partial
partially addressed in HEAD/RE24