Full_Name: Version: RE24 6f33e2c OS: URL: Submission from: (NULL) (2001:8d8:1fe:1:d6be:d9ff:fe06:a14f) It seems that operational attributes generated by slapo-allowed are replicated. Syslog shows: mods check (allowedAttributes: value #0 invalid per syntax)
On Tue, Jan 15, 2013 at 12:18:59PM +0000, michael@stroeder.com wrote: > Full_Name: > Version: RE24 6f33e2c > OS: > URL: > Submission from: (NULL) (2001:8d8:1fe:1:d6be:d9ff:fe06:a14f) > > > It seems that operational attributes generated by slapo-allowed are replicated. Works as designed. These attributes are directoryOperation, not DSA-specific. Closing this ITS. > Syslog shows: > mods check (allowedAttributes: value #0 invalid per syntax) >
On 01/15/2013 01:56 PM, hyc@symas.com wrote: > On Tue, Jan 15, 2013 at 12:18:59PM +0000, michael@stroeder.com wrote: >> Full_Name: >> Version: RE24 6f33e2c >> OS: >> URL: >> Submission from: (NULL) (2001:8d8:1fe:1:d6be:d9ff:fe06:a14f) >> >> >> It seems that operational attributes generated by slapo-allowed are replicated. > > Works as designed. These attributes are directoryOperation, not DSA-specific. I see the point; since they're generated by the overlay in response to search operations, either they should not be replicated, or replication should accept them. Their value depends on ACLs, so in order to reflect ACLs on a specific DSA they should be generated; however, I concur ACLs should not depend on the specific DSA of a replication setup. I'm open to suggestions about how to fix this. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano
On Tue, 15 Jan 2013 12:56:35 GMT hyc@symas.com wrote > > It seems that operational attributes generated by slapo-allowed are > > replicated. > > Works as designed. These attributes are directoryOperation, not DSA-specific. > Closing this ITS. The fact that slapo-allowed in contrib/ does not declare the attribute types as DSA-specific does not mean that they are not DSA-specific. I guess MS AD does not care about subschema DSA-specific or not so we have to apply common sense here. The allowed* attr values are supposed to be generated based on the local access control configuration. Since with OpenLDAP local configuration and therefore local ACLs can differ on different replicas these attrs MUST NOT be replicated. Please re-open the ITS. Ciao, Michael.
On Tue, 15 Jan 2013 13:37:06 GMT masarati@aero.polimi.it wrote > On 01/15/2013 01:56 PM, hyc@symas.com wrote: > > On Tue, Jan 15, 2013 at 12:18:59PM +0000, michael@stroeder.com wrote: > >> Full_Name: > >> Version: RE24 6f33e2c > >> OS: > >> URL: > >> Submission from: (NULL) (2001:8d8:1fe:1:d6be:d9ff:fe06:a14f) > >> > >> > >> It seems that operational attributes generated by slapo-allowed are > >> replicated. > > > Works as designed. These attributes are directoryOperation, not > > DSA-specific. > > I see the point; since they're generated by the overlay in response to > search operations, either they should not be replicated, or replication > should accept them. > > Their value depends on ACLs, so in order to reflect ACLs on a specific > DSA they should be generated; however, I concur ACLs should not depend > on the specific DSA of a replication setup. The values depend on local ACLs *and* current authz-DN. => These attributes MUST NOT be replicated. Ciao, Michael.
On Tue, 15 Jan 2013 13:37:06 GMT masarati@aero.polimi.it wrote > Their value depends on ACLs, so in order to reflect ACLs on a specific > DSA they should be generated; however, I concur ACLs should not depend > on the specific DSA of a replication setup. BTW: It does make sense to have different ACLs on different replicas! Think of a master with fine-grained ACLs for entry management and read-only consumers with simpler ACLs for better performance. Ciao, Michael.
Please consider the attached patch which sets allowed "USAGE dSAOperation". This seems to be the most appropriate USAGE comparable to what's set for entryTTL in slapo-dds. I, Michael Ströder, hereby place the attached modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. Ciao, Michael.
(Re-sent without S/MIME signature to make ITS software happy) Please consider the attached patch which sets allowed "USAGE dSAOperation". This seems to be the most appropriate USAGE comparable to what's set for entryTTL in slapo-dds. I, Michael Ströder, hereby place the attached modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. Ciao, Michael.
On 01/15/2013 07:40 PM, michael@stroeder.com wrote: > Please consider the attached patch which sets allowed > "USAGE dSAOperation". This seems to be the most appropriate USAGE compara= > ble > to what's set for entryTTL in slapo-dds. No objection with this patch, since those properties were "arbitrarily" assigned to attributes defined by others to provide software interoperability. Unless anyone has objections, I'd commit it. Thanks, p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano
masarati@aero.polimi.it wrote: > On 01/15/2013 07:40 PM, michael@stroeder.com wrote: > >> Please consider the attached patch which sets allowed >> "USAGE dSAOperation". This seems to be the most appropriate USAGE compara= >> ble >> to what's set for entryTTL in slapo-dds. > > No objection with this patch, since those properties were "arbitrarily" > assigned to attributes defined by others to provide software > interoperability. Unless anyone has objections, I'd commit it. Go ahead. Please add a comment about the origin of the schema definitions and these interoperability concerns. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
hyc@symas.com wrote: > masarati@aero.polimi.it wrote: >> On 01/15/2013 07:40 PM, michael@stroeder.com wrote: >> >>> Please consider the attached patch which sets allowed >>> "USAGE dSAOperation". This seems to be the most appropriate USAGE compara= >>> ble >>> to what's set for entryTTL in slapo-dds. >> >> No objection with this patch, since those properties were "arbitrarily" >> assigned to attributes defined by others to provide software >> interoperability. Unless anyone has objections, I'd commit it. > > Go ahead. Please add a comment about the origin of the schema definitions and > these interoperability concerns. These attribute type descriptions were roughly taken from MS AD. Today I've checked the subschema of a W2K8R2 AD server: I did not find a single attribute type description with USAGE although there were attribute types formally defined in RFCs. One example is 'entryTTL' defined with "USAGE dSAOperation" in RFC 2589 which in fact was co-authored by Microsoft employees. The official Microsoft documentation is here [MS-ADA1]: http://msdn.microsoft.com/en-us/library/cc219752.aspx Ciao, Michael.
Michael Ströder wrote: > hyc@symas.com wrote: >> masarati@aero.polimi.it wrote: >>> On 01/15/2013 07:40 PM, michael@stroeder.com wrote: >>> >>>> Please consider the attached patch which sets allowed >>>> "USAGE dSAOperation". This seems to be the most appropriate USAGE compara= >>>> ble >>>> to what's set for entryTTL in slapo-dds. >>> >>> No objection with this patch, since those properties were "arbitrarily" >>> assigned to attributes defined by others to provide software >>> interoperability. Unless anyone has objections, I'd commit it. >> >> Go ahead. Please add a comment about the origin of the schema definitions and >> these interoperability concerns. > > These attribute type descriptions were roughly taken from MS AD. I meant, please add a comment *in the patch* so it will remain in the source code. > Today I've checked the subschema of a W2K8R2 AD server: > I did not find a single attribute type description with USAGE although there > were attribute types formally defined in RFCs. One example is 'entryTTL' > defined with "USAGE dSAOperation" in RFC 2589 which in fact was co-authored by > Microsoft employees. > > The official Microsoft documentation is here [MS-ADA1]: > > http://msdn.microsoft.com/en-us/library/cc219752.aspx > > Ciao, Michael. >
> Michael Ströder wrote: >> hyc@symas.com wrote: >>> masarati@aero.polimi.it wrote: >>>> On 01/15/2013 07:40 PM, michael@stroeder.com wrote: >>>> >>>>> Please consider the attached patch which sets allowed >>>>> "USAGE dSAOperation". This seems to be the most appropriate USAGE >>>>> compara= >>>>> ble >>>>> to what's set for entryTTL in slapo-dds. >>>> >>>> No objection with this patch, since those properties were >>>> "arbitrarily" >>>> assigned to attributes defined by others to provide software >>>> interoperability. Unless anyone has objections, I'd commit it. >>> >>> Go ahead. Please add a comment about the origin of the schema >>> definitions and >>> these interoperability concerns. >> >> These attribute type descriptions were roughly taken from MS AD. > > I meant, please add a comment *in the patch* so it will remain in the > source code. There's already a detailed comment to this end in the related README, which links the attribute definitions on <http://msdn.microsoft.com/>. p. >> Today I've checked the subschema of a W2K8R2 AD server: >> I did not find a single attribute type description with USAGE although >> there >> were attribute types formally defined in RFCs. One example is 'entryTTL' >> defined with "USAGE dSAOperation" in RFC 2589 which in fact was >> co-authored by >> Microsoft employees. >> >> The official Microsoft documentation is here [MS-ADA1]: >> >> http://msdn.microsoft.com/en-us/library/cc219752.aspx >> >> Ciao, Michael. >> > > > > -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano
masarati@aero.polimi.it wrote: >> Michael Ströder wrote: >>> hyc@symas.com wrote: >>>> masarati@aero.polimi.it wrote: >>>>> On 01/15/2013 07:40 PM, michael@stroeder.com wrote: >>>>> >>>>>> Please consider the attached patch which sets allowed >>>>>> "USAGE dSAOperation". This seems to be the most appropriate USAGE >>>>>> compara= >>>>>> ble >>>>>> to what's set for entryTTL in slapo-dds. >>>>> >>>>> No objection with this patch, since those properties were >>>>> "arbitrarily" >>>>> assigned to attributes defined by others to provide software >>>>> interoperability. Unless anyone has objections, I'd commit it. >>>> >>>> Go ahead. Please add a comment about the origin of the schema >>>> definitions and >>>> these interoperability concerns. >>> >>> These attribute type descriptions were roughly taken from MS AD. >> >> I meant, please add a comment *in the patch* so it will remain in the >> source code. > > There's already a detailed comment to this end in the related README, > which links the attribute definitions on <http://msdn.microsoft.com/>. As already noted, those links don't provide actual schema definitions, nor do they define the USAGE. We're making a judgement call here with no documentation to support it. We should document why we're defining it this way so we don't have to repeat this conversation again down the road. > > p. > >>> Today I've checked the subschema of a W2K8R2 AD server: >>> I did not find a single attribute type description with USAGE although >>> there >>> were attribute types formally defined in RFCs. One example is 'entryTTL' >>> defined with "USAGE dSAOperation" in RFC 2589 which in fact was >>> co-authored by >>> Microsoft employees. >>> >>> The official Microsoft documentation is here [MS-ADA1]: >>> >>> http://msdn.microsoft.com/en-us/library/cc219752.aspx >>> >>> Ciao, Michael. >>> >> >> >> >> > >
changed notes changed state Open to Test moved from Incoming to Software Bugs
Any chance to see this patch appear in 2.4.34? Ciao, Michael.
changed notes changed state Test to Release
changed notes changed state Release to Closed
fixed in HEAD fixed in RE24