Bug 1304682 - "stale" automember rule (associated to a removed group) causes discrepancies in the database
"stale" automember rule (associated to a removed group) causes discrepancies ...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
7.3
Unspecified Unspecified
unspecified Severity high
: rc
: ---
Assigned To: Noriko Hosoi
Viktor Ashirov
Petr Bokoc
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-04 05:53 EST by Michele Casaburo
Modified: 2016-11-03 16:39 EDT (History)
10 users (show)

See Also:
Fixed In Version: 389-ds-base-1.3.5.9-1.el7
Doc Type: Bug Fix
Doc Text:
Entries rejected by multiple plug-ins no longer show up in searches Previously, when an entry was rejected by multiple back end transaction plug-ins (for example, *Auto Membership* or *Managed Entry*) at the same time, the entry cache was left in an inconsistent state. This allowed a search to return the entry even though it was not added. With this update, the entry cache which stores the Distinguished Name (DN) of the entry is properly cleaned up when an "add" operation fails, and rejected entries are no longer returned by "ldapsearch".
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-03 16:39:26 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michele Casaburo 2016-02-04 05:53:22 EST
Description of problem:
Having a automember rule associated to a group, then removing the group, the automember rule stays in place and active.

Trying to add a user which matches the rule I get:
# ipa user-add test6_auto --first=test --last=test
ipa: ERROR: Server is unwilling to perform: Managed Entry Plugin rejected add operation (see errors log).

which is expected but if I try to add the same user again I get:
# ipa user-add test6_auto --first=test --last=test
ipa: ERROR: user with name "test6_auto" already exists

# ipa user-find | grep test6_auto
#

but:
# ipa user-show test6_auto --all --raw
  dn: uid=test6_auto,cn=users,cn=accounts,dc=example1,dc=com
  uid: test6_auto
  givenname: test
  sn: test
  cn: test test
  initials: tt
  homedirectory: /home/test6_auto
  gecos: test test
  loginshell: /bin/sh
  mail: test6_auto@example1.com
  uidnumber: 1826600009
  gidnumber: 1826600009
  nsaccountlock: FALSE
  has_password: FALSE
  has_keytab: FALSE
  displayName: test test
  ipaUniqueID: 77e02950-cb26-11e5-948b-525400930e50
  krbPrincipalName: test6_auto@EXAMPLE1.COM
  mepManagedEntry: cn=test6_auto,cn=groups,cn=accounts,dc=example1,dc=com
  objectClass: ipaobject
  objectClass: person
  objectClass: top
  objectClass: ipasshuser
  objectClass: inetorgperson
  objectClass: organizationalperson
  objectClass: krbticketpolicyaux
  objectClass: krbprincipalaux
  objectClass: inetuser
  objectClass: posixaccount
  objectClass: ipaSshGroupOfPubKeys
  objectClass: mepOriginEntry

trying to delete the user gives:
# ipa user-del test6_auto
ipa: ERROR: test6_auto: user not found

If it can be of any relevance Looking at a user created _before_ the removal of the group we have 
# ipa user-find | grep test2_auto
  User login: test2_auto
  Home directory: /home/test2_auto
  Email address: test2_auto@example1.com

# ipa user-show test2_auto --all --raw
  dn: uid=test2_auto,cn=users,cn=accounts,dc=example1,dc=com
  uid: test2_auto
  givenname: test
  sn: test
  cn: test test
  initials: tt
  homedirectory: /home/test2_auto
  gecos: test test
  loginshell: /bin/sh
  mail: test2_auto@example1.com
  uidnumber: 1826600004
  gidnumber: 1826600004
  nsaccountlock: FALSE
  has_password: FALSE
  has_keytab: FALSE
  displayName: test test
  ipaUniqueID: 0bb91e2c-cb1b-11e5-9520-525400930e50
  krbPrincipalName: test2_auto@EXAMPLE1.COM
  memberof: cn=ipausers,cn=groups,cn=accounts,dc=example1,dc=com
  mepManagedEntry: cn=test2_auto,cn=groups,cn=accounts,dc=example1,dc=com
  objectClass: ipaobject
  objectClass: person
  objectClass: top
  objectClass: ipasshuser
  objectClass: inetorgperson
  objectClass: organizationalperson
  objectClass: krbticketpolicyaux
  objectClass: krbprincipalaux
  objectClass: inetuser
  objectClass: posixaccount
  objectClass: ipaSshGroupOfPubKeys
  objectClass: mepOriginEntry

the "only" apparent difference is the memberof attribute which is entirely missing for the "problematic" user

ldapsearches run agains dirsrv looks to me weird as well:

# ldapsearch -x -w redhat123 -D "cn=Directory Manager" -h localhost -b "uid=test6_auto,cn=users,cn=accounts,dc=example1,dc=com"
[...]
# test6_auto, users, accounts, example1.com
dn: uid=test6_auto,cn=users,cn=accounts,dc=example1,dc=com
displayName: test test
uid: test6_auto
[...]

no results for the below:
# ldapsearch -x -w redhat123 -D "cn=Directory Manager" -h localhost -b "cn=users,cn=accounts,dc=example1,dc=com" | grep test6_auto
#

I may be wrong, but I would not expect it

Version-Release number of selected component (if applicable):
# rpm -q  ipa-server
ipa-server-4.2.0-15.el7_2.3.x86_64

# rpm -q 389-ds-base
389-ds-base-1.3.4.0-21.el7_2.x86_64


How reproducible:
Above for verbose description

Steps to Reproduce:
1. # ipa group-add aumember_group
2. # ipa automember-add aumember_group --type group
3. # ipa automember-add-condition aumember_group --type group --inclusive-regex=.*auto
4. # ipa group-remove aumember_group
5  # ipa user-add test_auto --first=test --last=test

Actual results:

user gets partially created, but it is not usable/removable

Expected results:

no personal preference, but it would be nice to expect one of the following:

1) user creation fails completely
or
2) user creation succeeds normally


I would probably go for the second _and_ printing the warning/error from the automember rule

Additional info:
Comment 4 thierry bordaz 2016-02-04 07:01:56 EST
	- The following entry can be found be found with a search base or subtree
	  but only with filter 'objectclass=*'
dn: uid=test5_auto,cn=users,cn=accounts,dc=example1,dc=com
nscpentrywsi: dn: uid=test5_auto,cn=users,cn=accounts,dc=example1,dc=com
nscpentrywsi: displayName: test test
nscpentrywsi: uid: test5_auto
nscpentrywsi: objectClass: ipaobject
nscpentrywsi: objectClass: person
nscpentrywsi: objectClass: top
nscpentrywsi: objectClass: ipasshuser
nscpentrywsi: objectClass: inetorgperson
nscpentrywsi: objectClass: organizationalperson
nscpentrywsi: objectClass: krbticketpolicyaux
nscpentrywsi: objectClass: krbprincipalaux
nscpentrywsi: objectClass: inetuser
nscpentrywsi: objectClass: posixaccount
nscpentrywsi: objectClass: ipaSshGroupOfPubKeys
nscpentrywsi: objectClass: mepOriginEntry
nscpentrywsi: loginShell: /bin/sh
nscpentrywsi: initials: tt
nscpentrywsi: gecos: test test
nscpentrywsi: sn: test
nscpentrywsi: homeDirectory: /home/test5_auto
nscpentrywsi: mail: test5_auto@example1.com
nscpentrywsi: krbPrincipalName: test5_auto@EXAMPLE1.COM
nscpentrywsi: givenName: test
nscpentrywsi: cn: test test
nscpentrywsi: creatorsName: uid=admin,cn=users,cn=accounts,dc=example1,dc=com
nscpentrywsi: modifiersName: cn=Managed Entries,cn=plugins,cn=config
nscpentrywsi: createTimestamp: 20160204085642Z
nscpentrywsi: modifyTimestamp: 20160204085642Z
nscpentrywsi: nsUniqueId: 2b8fc285-cb1d11e5-99a8a95a-3981a25f
nscpentrywsi: ipaUniqueID: 3645a73a-cb1d-11e5-ae9b-525400930e50
nscpentrywsi: parentid: 3
nscpentrywsi: entryid: 426
nscpentrywsi: uidNumber: 1826600008
nscpentrywsi: gidNumber: 1826600008
nscpentrywsi: entryusn: 9483
nscpentrywsi: mepManagedEntry: cn=test5_auto,cn=groups,cn=accounts,dc=example1
 ,dc=com

	- The entry does not exist in the id2entry database and none of its
	  attribute has been indexed

	- The updates that created that entry was
[04/Feb/2016:09:56:42 +0100] conn=6 op=8 ADD dn="uid=test5_auto,cn=users,cn=accounts,dc=example1,dc=com"
[04/Feb/2016:09:56:42 +0100] conn=6 op=8 RESULT err=53 tag=105 nentries=0 etime=0
	  err=53 LDAP_NO_OBJECT_CLASS_MODS

	  Along with automember/mep logs
[04/Feb/2016:09:56:42 +0100] auto-membership-plugin - automember_add_member_value: Unable to add "uid=test5_auto,cn=users,cn=accounts,dc=example1,dc=com" as a "member" value to group "cn=aumember_group,cn=groups,cn=accounts,dc=example1,dc=com" (No such object).
[04/Feb/2016:09:56:42 +0100] auto-membership-plugin - automember_add_member_value: Unable to add "uid=test5_auto,cn=users,cn=accounts,dc=example1,dc=com" as a "member" value to group "cn=aumember_group,cn=groups,cn=accounts,dc=example1,dc=com" (No such object).
[04/Feb/2016:09:56:42 +0100] managed-entries-plugin - mep_add_managed_entry: Unable to add managed entry "cn=test5_auto,cn=groups,cn=accounts,dc=example1,dc=com" for origin entry "uid=test5_auto,cn=users,cn=accounts,dc=example1,dc=com" (Already exists).



	In conclusion:
		It is looking like the entry failed to be added in the DB/index but was not flush from the entry cache.
	The possible reasons of the failure to ADD are
		- configuration issue of automember because "cn=aumember_group,cn=groups,cn=accounts,dc=example1,dc=com"
                  does not exist
                - a schema issue where automember seems to be unable to add "member" attribute
	The fact that the entry is in the entry cache but not store is a bug
Comment 8 Noriko Hosoi 2016-02-15 12:28:43 EST
Upstream ticket:
https://fedorahosted.org/389/ticket/48637
Comment 13 mreynolds 2016-06-22 15:13:20 EDT
automember plugin is behaving as expected, but the issue with the entry being returned by a search after it was NOT added has been fixed upstream.
Comment 15 Simon Pichugin 2016-07-13 16:48:57 EDT
Build tested:
389-ds-base-1.3.5.10-3.el7.x86_64

============================= test session starts =============================
platform linux2 -- Python 2.7.5, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 -- /usr/bin/python
cachedir: dirsrvtests/tests/tickets/.cache
rootdir: /mnt/tests/rhds/tests/upstream/ds/dirsrvtests/tests/tickets, inifile:
plugins: html-1.9.0, cov-2.3.0
collected 1 items

dirsrvtests/tests/tickets/ticket48637_test.py::test_ticket48637 PASSED

========================== 1 passed in 25.56 seconds ==========================

Marking as verified.
Comment 17 errata-xmlrpc 2016-11-03 16:39:26 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2594.html

Note You need to log in before you can comment on or make changes to this bug.