Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/pierangelo-masarati-2006-11-03-allowed.c Submission from: (NULL) (81.72.89.40) Submitted by: ando This overlay provides simple support for allowedAttributes and allowedAttributesEffective, a (somewhat broken) AD feature that is intended to help GUIs into determining, based on the current objectClass values of an object, what attributes would comply with the schema (without distinction between "allowed" and "required"), by listing them in "allowedAttributes", and, furthermore, by providing a hint to what of those values could be effectively added by the current connection, by listing them in "allowedAttributesEffective". This is broken since it doesn't consider the possibility of value-dependent ACLs, so it should really be considered just a hint, while the "allowedAttributes" could really be computed starting from the schema definition, which remains the recommended way to solve the problem So this overlay should really be considered only food for thought as a starting base for a tighter integration of OpenLDAP into Samba4. There's minimal support for "allowedChildClasses" and "allowedChildClassesEffective", whose definition is absolutely obscure to me, as I believe the only classes that can be added to an existing object are all the AUXILIARY ones, while considering what are effectively allowed implies getting into value-dependent ACLs. Some discussion can be found here (follow the thread) <http://www.redhat.com/archives/fedora-directory-devel/2006-November/msg00000.html> while portions of the schema definition has been taken from here <http://www.redhat.com/archives/fedora-directory-devel/2006-August/msg00007.html> p.
moved from Incoming to Contrib
> This overlay provides simple support for allowedAttributes and > allowedAttributesEffective, a (somewhat broken) AD feature that is > intended to > help GUIs into determining, based on the current objectClass values of an > object, what attributes would comply with the schema (without distinction > between "allowed" and "required"), by listing them in "allowedAttributes", This could be made more useful by providing ";x-allowed" or ";x-required" options to "allowedAttributes", so that GUI developers can easily handle mandatory vs. optional fields. However, I bet this would break existing applications that make use of those attributes. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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 ------------------------------------------
I'd be interested to add support for something like this to my LDAP client. BTW: I'd vote against ";x-allowed" or ";x-required" since a schema-aware client can already determine this in a non-proprietary way from the subschema. The overlay's source is quite old. Does it still build with recent HEAD? Ciao, Michael.
Hi, michael@stroeder.com a écrit : > I'd be interested to add support for something like this to my LDAP client. > > BTW: I'd vote against ";x-allowed" or ";x-required" since a schema-aware > client can already determine this in a non-proprietary way from the subschema. > > The overlay's source is quite old. Does it still build with recent HEAD? I'm also interested in an overlay of this type. I started hacking into it recently, and don't remember any problems getting it to build on HEAD (a couple of months ago). This was related to an implementation of Get Effective Rights [1], which returns rights the current user has on each attribute in an object. I had a premilinary working version, but it did not work as a control, just returned extra attributes. Similarly, this would be useful to LDAP GUI clients. If you're interested, I could dig out the code. [1] http://directory.fedoraproject.org/wiki/Get_Effective_Rights_Design and http://www.ietf.org/proceedings/01dec/I-D/draft-ietf-ldapext-acl-model-08.txt Regards, Jonathan -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com
HI! I've added support for 'allowedAttributesEffective' in web2ldap recently which works with AD. I tried this overlay but it seg faults with recent OpenLDAP version. Any chance to get this back on the radar? Ciao, Michael.
> HI! > > I've added support for 'allowedAttributesEffective' in web2ldap recently > which > works with AD. I tried this overlay but it seg faults with recent OpenLDAP > version. Any chance to get this back on the radar? Not *now*, possibly shortly. p.
> HI! > > I've added support for 'allowedAttributesEffective' in web2ldap recently > which > works with AD. I tried this overlay but it seg faults with recent OpenLDAP > version. Any chance to get this back on the radar? Michael, I've built and tested my copy of allowed.c with HEAD and re24 and it works as expected. However, I might have modified it to keep pace with baseline code evolution without resubmitting modifications. I can't check right now but I will. If needed, I'll resubmit the modified code, so consider it done. The main reason I didn't put it directly in contrib/ is that at that time I was considering the opportunity of packaging all contributions and customizations intended for samba4 in something as self contained as possible (in the end, supporting all samba4 related extensions may result in stacking dozens of overlays, which may result in overhead and possibly in incompatibilities, something we might need to deal with at some point). However, as your interest seems to revitalize this feature, I see no objection in putting it at least in contrib (if there's enough consensus). p.
masarati@aero.polimi.it wrote: >> >> I've added support for 'allowedAttributesEffective' in web2ldap recently >> which >> works with AD. I tried this overlay but it seg faults with recent OpenLDAP >> version. Any chance to get this back on the radar? > > I've built and tested my copy of allowed.c with HEAD and re24 and it works > as expected. However, I might have modified it to keep pace with baseline > code evolution without resubmitting modifications. I can't check right > now but I will. If needed, I'll resubmit the modified code, so consider > it done. > > The main reason I didn't put it directly in contrib/ is that at that time > I was considering the opportunity of packaging all contributions and > customizations intended for samba4 in something as self contained as > possible (in the end, supporting all samba4 related extensions may result > in stacking dozens of overlays, which may result in overhead and possibly > in incompatibilities, something we might need to deal with at some point). > > However, as your interest seems to revitalize this feature, I see no > objection in putting it at least in contrib (if there's enough consensus). I'd highly appreciate to find copy under contrib/. Other people I know also have interest in that. Many thanks. Ciao, Michael.
On 17/08/2009 11:09, michael@stroeder.com wrote: > masarati@aero.polimi.it wrote: >>> >>> I've added support for 'allowedAttributesEffective' in web2ldap recently >>> which >>> works with AD. I tried this overlay but it seg faults with recent OpenLDAP >>> version. Any chance to get this back on the radar? >> >> I've built and tested my copy of allowed.c with HEAD and re24 and it works >> as expected. However, I might have modified it to keep pace with baseline >> code evolution without resubmitting modifications. I can't check right >> now but I will. If needed, I'll resubmit the modified code, so consider >> it done. >> >> The main reason I didn't put it directly in contrib/ is that at that time >> I was considering the opportunity of packaging all contributions and >> customizations intended for samba4 in something as self contained as >> possible (in the end, supporting all samba4 related extensions may result >> in stacking dozens of overlays, which may result in overhead and possibly >> in incompatibilities, something we might need to deal with at some point). >> >> However, as your interest seems to revitalize this feature, I see no >> objection in putting it at least in contrib (if there's enough consensus). > > I'd highly appreciate to find copy under contrib/. Other people I know also > have interest in that. Many thanks. Absolutely, I for one am very interested. Looking forward to it :) Jonathan
>> HI! >> >> I've added support for 'allowedAttributesEffective' in web2ldap recently >> which >> works with AD. I tried this overlay but it seg faults with recent >> OpenLDAP >> version. Any chance to get this back on the radar? > > Michael, > > I've built and tested my copy of allowed.c with HEAD and re24 and it works > as expected. However, I might have modified it to keep pace with baseline > code evolution without resubmitting modifications. My version was indeed rather modified, that's why it worked. It's now in HEAD's contrib/slapd-modules/allowed/. It builds fine with HEAD and re24; it should also build with OL 2.3, although I haven't checked in a while. Please test and report. p.
changed notes changed state Open to Test moved from Contrib to Development
masarati@aero.polimi.it wrote: >>> HI! >>> >>> I've added support for 'allowedAttributesEffective' in web2ldap recently >>> which >>> works with AD. I tried this overlay but it seg faults with recent >>> OpenLDAP >>> version. Any chance to get this back on the radar? >> >> I've built and tested my copy of allowed.c with HEAD and re24 and it works >> as expected. However, I might have modified it to keep pace with baseline >> code evolution without resubmitting modifications. > > My version was indeed rather modified, that's why it worked. It's now in > HEAD's contrib/slapd-modules/allowed/. It builds fine with HEAD and re24; > it should also build with OL 2.3, although I haven't checked in a while. > Please test and report. I've created a simple Makefile derived from the one for slapo-smbk5pwd for this I'd like to contribute if appropriate. Please review. I grant *all* rights to the OpenLDAP project. Now for the concrete testing: In principle it works. That's great! There's a special corner-case: If the user bound (e.g. anonymous in my test configuration) has no write access to any attribute an empty attribute value list is returned for 'allowedAttributesEffective'. Indeed this is helpful since my web2ldap can then distinguish between this attribute being not available at all or no attributes are allowed to be written. But I'm not sure whether that complies to the LDAP data model. What do you think? Ciao, Michael.
> I've created a simple Makefile derived from the one for slapo-smbk5pwd for > this I'd like to contribute if appropriate. Please review. I grant *all* > rights to the OpenLDAP project. > > Now for the concrete testing: > > In principle it works. That's great! > > There's a special corner-case: > If the user bound (e.g. anonymous in my test configuration) has no write > access to any attribute an empty attribute value list is returned for > 'allowedAttributesEffective'. You mean an instance of the allowedAttributesEffective with the empty value? I'm not seeing anything like that. > Indeed this is helpful since my web2ldap can > then distinguish between this attribute being not available at all or no > attributes are allowed to be written. But I'm not sure whether that > complies > to the LDAP data model. What do you think? In any case, I'd consider it an error, which deserves to be fixed. p.
> You mean an instance of the allowedAttributesEffective with the empty > value? I'm not seeing anything like that. Actually, I confirm I didn't see anything like that, but there was a bug: the attribute was being added regardless of having any value, and the a_numvals field was not being filled in any case. Fixing... p.
masarati@aero.polimi.it wrote: > Michael Ströder wrote: >> There's a special corner-case: >> If the user bound (e.g. anonymous in my test configuration) has no write >> access to any attribute an empty attribute value list is returned for >> 'allowedAttributesEffective'. > > You mean an instance of the allowedAttributesEffective with the empty > value? Yes. Here's the python-ldap trace log: Note the 'allowedAttributesEffective': [] in the result. I can also enable OpenLDAP debugging log if that would be more evidence for you. ---------------------------- snip ---------------------------- *** ldap://localhost:2071 - LDAPObject.search_ext (('ou=schulung,dc=stroeder,dc=local', 0, '(objectClass=*)', ['hasSubordinates', 'entryCSN', 'tokenGroupsGlobalAndUniversal', 'localEntryID', 'createTimestamp', 'uSNCreated', 'fromEntry', 'administrativeRole', 'structuralObjectClass', 'mS-DS-CreatorSID', 'msDS-Approx-Immed-Subordinates', 'nsAccountLock', 'authzTo', 'nsLookthroughLimit', 'GUID', 'authzFrom', '*', 'passwordExpWarned', 'whenChanged', 'modifiersName', 'isMemberOf', 'sDRightsEffective', 'governingStructureRule', 'primaryGroupToken', 'pwdPolicySubentry', 'accountUnlockTime', 'passwordHistory', 'subordinateCount', 'allowedAttributesEffective', 'creatorsName', 'entryUUID', 'aclentry', 'uSNChanged', 'tokenGroupsNoGCAcceptable', 'entryDN', 'passwordRetryCount', 'tokenGroups', 'passwordExpirationTime', 'aci', 'passwordAllowChangeTime', 'whenCreated', 'retryCountResetTime', 'canonicalName', 'entryUSN', 'subschemaSubentry', 'numSubordinates', 'modifyTimestamp'], 0, [], None, 300, 0),{}) => result: 13 *** ldap://localhost:2071 - LDAPObject.result3 ((13, 1, 300),{}) => result: (101, [('ou=schulung,dc=stroeder,dc=local', {'hasSubordinates': ['TRUE'], 'entryCSN': ['20090818120115.850129Z#000000#000#000000'], 'objectClass': ['organizationalUnit'], 'creatorsName': ['uid=diradm,ou=schulung,dc=stroeder,dc=local'], 'entryUUID': ['d0ed3070-150d-4a5a-bec3-5c21e78c31c3'], 'allowedAttributesEffective': [], 'modifiersName': ['uid=diradm,ou=schulung,dc=stroeder,dc=local'], 'createTimestamp': ['20090818120115Z'], 'entryDN': ['ou=schulung,dc=stroeder,dc=local'], 'subschemaSubentry': ['cn=Subschema'], 'structuralObjectClass': ['organizationalUnit'], 'ou': ['schulung'], 'modifyTimestamp': ['20090818120115Z']})], 13, []) ---------------------------- snip ---------------------------- > I'm not seeing anything like that. At which level? >> Indeed this is helpful since my web2ldap can >> then distinguish between this attribute being not available at all or no >> attributes are allowed to be written. But I'm not sure whether that >> complies >> to the LDAP data model. What do you think? > > In any case, I'd consider it an error, which deserves to be fixed. If you fix it with hunking out the empty values list the distinction within web2ldap would be then to look at the schema and decide whether allowedAttributesEffective is available. I can see that attr type description of allowedAttributesEffective is hard-coded in allowed.c so that seems fairly reliable to me. Ciao, Michael.
masarati@aero.polimi.it wrote: >> You mean an instance of the allowedAttributesEffective with the empty >> value? I'm not seeing anything like that. > > Actually, I confirm I didn't see anything like that, but there was a bug: > the attribute was being added regardless of having any value, and the > a_numvals field was not being filled in any case. Fixing... Yupp, that seems right now. Ciao, Michael.
changed notes changed state Test to Release
changed notes changed state Release to Closed
in HEAD in RE24