#18 Make sure ID overrides changes update AD user/group entries in a map cache
Opened 4 years ago by abbra. Modified 4 years ago

Currently a change in an override is only in the compat tree after a restart of 389ds.

There seems to be a possibility to improve this and make the changes available at runtime.

A test case is following:

# sss_cache -u administrator@ad.ipa.cool
# ldapsearch -x -b cn=compat,dc=xs,dc=ipa,dc=cool  -LLL  -o ldif-wrap=no '(&(objectclass=posixaccount)(uid=administrator@ad.ipa.cool))'
dn: uid=administrator@ad.ipa.cool,cn=users,cn=compat,dc=xs,dc=ipa,dc=cool
cn: Administrator
objectClass: posixAccount
objectClass: top
gidNumber: 967000500
gecos: Administrator
uidNumber: 967000500
homeDirectory: /home/ad.ipa.cool/administrator
uid: administrator@ad.ipa.cool

# sss_cache -u administrator@ad.ipa.cool
# ipa idoverrideuser-add 'Default Trust View' administrator@ad.ipa.cool --gecos=FooIsBaX
--------------------------------------------------
Added User ID override "administrator@ad.ipa.cool"
--------------------------------------------------
  Anchor to override: administrator@ad.ipa.cool
  GECOS: FooIsBaX

# ldapsearch -x -b cn=compat,dc=xs,dc=ipa,dc=cool  -LLL  -o ldif-wrap=no '(&(objectclass=posixaccount)(uid=administrator@ad.ipa.cool))'
dn: uid=administrator@ad.ipa.cool,cn=users,cn=compat,dc=xs,dc=ipa,dc=cool
cn: Administrator
objectClass: posixAccount
objectClass: top
gidNumber: 967000500
gecos: Administrator
uidNumber: 967000500
homeDirectory: /home/ad.ipa.cool/administrator
uid: administrator@ad.ipa.cool

Expected result is that a change from ID override in Default Trust View would update entry of that user/group in the compat tree. E.g.

# sss_cache -u administrator@ad.ipa.cool
# ldapsearch -x -b cn=compat,dc=xs,dc=ipa,dc=cool  -LLL  -o ldif-wrap=no '(&(objectclass=posixaccount)(uid=administrator@ad.ipa.cool))'
dn: uid=administrator@ad.ipa.cool,cn=users,cn=compat,dc=xs,dc=ipa,dc=cool
cn: FooIsBaX
objectClass: posixAccount
objectClass: top
gidNumber: 967000500
gecos: FooIsBaX
uidNumber: 967000500
loginShell: /bin/bash
homeDirectory: /home/ad.ipa.cool/administrator
uid: administrator@ad.ipa.cool

Metadata Update from @abbra:
- Issue assigned to abbra

4 years ago

Metadata Update from @abbra:
- Issue set to the milestone: 0.56.2

4 years ago

Metadata Update from @abbra:
- Custom field Red Hat buzilla adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1473572

4 years ago

Metadata Update from @abbra:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1473572

4 years ago

@abbra, the patch is really great and I have very few comments about it

  • In your final patch it is looking like you do not need to rename backend_build_dn into format_build_dn. I am missing something ? If not you could avoid that change.

  • backend_entry_is_add_related (called on MOD/ADD/DEL) basically checks if the target entry is an AD user/group and remove the related ID_overwrite entry from the map. I do not like the name I would prefer that something like 'backend_entry_del_idoverwrite'.
    Also the return code is only tested to log a message if the overwrite entry was or not found in the map. Why not logging the message into backend_entry_del_idoverwrite and just return void.

@tbordaz, thanks for the review. Regarding the second part, I think we are going to add more helpers like these. Right now, there is no need for returning a code that would be analyzed by a caller. However, for generic use, the caller would need to perform a certain operation in case there was no action performed by those callbacks. Thus a choice of the non-void return code.

I changed method name to backend_entry_evict_if_related(). This would be more appropriate than what you proposed because we aren't deleting the ID override itself. Instead, we are removing backend entry from a map cache.

I'll drop the first patch from this patchset -- it is needed for logically unifying code in upstream but not for this particular fix.

Login to comment on this ticket.

Metadata
Attachments 1