#47761 Return all attributes in rootdse without explicit request
Closed: wontfix None Opened 9 years ago by simo.

A recent change in schema parsing ahd the side effect of changing the behavior of rootdse so that now it does not return all atributes by default.
Although this is more standards complaint it may break clients that are primarily tested against Active Directory.

In FreeIPA we feel we need a way to change the behavior through a cn=config option so that we can return to the old behavior and return all attributes that were previously returned (but not things like modifyTimestamps and such).


One way of implementing this would be to allow the rootDSE attributes that should always be returned to be listed in the config. When processing a rootDSE search, the server would simply add these attributes to the requested attributes. If we do it this way, it allows for flexibility with regards to what attributes are returned and which are not by default.

From the old email thread "rootdse search result?"

commit ee7565f
Author: Rich Megginson rmeggins@redhat.com
Date: Thu Dec 19 10:49:27 2013 -0700

Ticket #47634 support AttributeTypeDescription USAGE userApplications distributedOperation dSAOperation

https://fedorahosted.org/389/ticket/47634
Reviewed by: nhosoi (Thanks!)
Branch: master
Fix Description: When reading schema, flag the attribute as distributedOperation
or dSAOperation.  When writing schema, make sure the USAGE is specified
correctly based on the flag.

Once the above patch is applied, ldapsearch on the rootdse with no attribute list returns just these attribute values:

$ ldapsearch -b "" -s base
dn:
objectClass: top
defaultnamingcontext: o=my.com
dataversion: 020140122182357
netscapemdsuffix: cn=ldap://dc=totoro,dc=usersys,dc=redhat,dc=com:10389

Rich Megginson wrote:

It is correct for LDAPv3

BUT

this will probably break customer apps (and ipa? dogtag? 389 console?) that expect all attributes to be returned in a rootdse search :-(

so

Either we bite the bullet and just make sure we warn customers ahead of time, and proactively fix ipa/dogtag/console/etc., and prepare ourselves to fix incoming bugs/issues

or

add yet another config attribute, which allows those attributes to be marked correctly in the schema, but not mark them as operational, so they will be returned in searches by default in the rootdse, and possibly elsewhere they are used. Or add a config attribute which causes rootdse searches to return all attributes, even operational attributes.

Replying to [comment:2 nkinder]:

One way of implementing this would be to allow the rootDSE attributes that should always be returned to be listed in the config. When processing a rootDSE search, the server would simply add these attributes to the requested attributes. If we do it this way, it allows for flexibility with regards to what attributes are returned and which are not by default.

yes, that seems to be the only way to resolve this, but I see two different ways to do so
1] add an attribute to cn=config listing the attributes to be returned, eg nsslapd-default-return-rootdse
2] add an attribute to the rootDSE entry itself to specify the default attributes, eg nsslapd-default-returned-attrs, this would allow to get the attrs directly from the rootDSE entry when it is returned (and could be applied to other entries as well), but would require the attribute to be in the schema

One decision to be made with both approches is if there should be one attribute value containing a [comma|space] separated list of attrs to return or if the attr should be multivalued

Replying to [comment:6 lkrispen]:

Replying to [comment:2 nkinder]:

One way of implementing this would be to allow the rootDSE attributes that should always be returned to be listed in the config. When processing a rootDSE search, the server would simply add these attributes to the requested attributes. If we do it this way, it allows for flexibility with regards to what attributes are returned and which are not by default.

yes, that seems to be the only way to resolve this, but I see two different ways to do so
1] add an attribute to cn=config listing the attributes to be returned, eg nsslapd-default-return-rootdse
2] add an attribute to the rootDSE entry itself to specify the default attributes, eg nsslapd-default-returned-attrs, this would allow to get the attrs directly from the rootDSE entry when it is returned (and could be applied to other entries as well), but would require the attribute to be in the schema

One decision to be made with both approches is if there should be one attribute value containing a [comma|space] separated list of attrs to return or if the attr should be multivalued

I would much rather this be a multi-valued attribute. Every time we introduce yet another field that requires a custom parser to be designed/written/tested/debugged, and angel loses its wings.

$ git merge ticket47761
Updating 2079892..c6167e7
Fast-forward
ldap/schema/01core389.ldif | 1 +
ldap/servers/slapd/result.c | 17 +++++++++++++++++
ldap/servers/slapd/slap.h | 1 +
3 files changed, 19 insertions(+)
$ git push origin master
Counting objects: 17, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (9/9), 1.40 KiB, done.
Total 9 (delta 7), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
2079892..c6167e7 master -> master

I did some testing when trying to leverage the nsslapd-return-default-opattr in IPA. I was not able to set the attribute on the upgraded instance. Ludvig confirms that this is an issue, so reopening the ticket.

Tomas confirmed that the feature works if the list of attributes to return is correctly added to the root entry instead of cn=config.
Closing again

Hi Simon,

We are currently in the process of making all our lib389 tests python 3 compliant. I also have a patch out for review on this topic(https://fedorahosted.org/389/ticket/48204). So the test script looks fine to me, but I can see you need to make this change to several places in your script:

{{{
except ldap.LDAPError, e:
}}}

to

{{{
except ldap.LDAPError as e:
}}}

Thanks,
Mark

Hi Mark,

sure. This patch was before your patch, and now it is fixed.

Thank you,
Simon

0584156..cb950de master -> master
commit cb950de
Author: Simon Pichugin spichugi@redhat.com
Date: Mon Aug 31 10:54:21 2015 +0200

7638651..973d1d9 389-ds-base-1.3.4 -> 389-ds-base-1.3.4
commit 973d1d9

Metadata Update from @spichugi:
- Issue assigned to lkrispen
- Issue set to the milestone: 1.3.3 - 6/14 (June)

7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1093

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

3 years ago

Login to comment on this ticket.

Metadata