Bug 1888863
| Summary: | group rdn with leading space char and add fails error 21 invalid syntax and delete fails error 32 | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Marc Sauton <msauton> | |
| Component: | 389-ds-base | Assignee: | mreynolds | |
| Status: | CLOSED ERRATA | QA Contact: | RHDS QE <ds-qe-bugs> | |
| Severity: | high | Docs Contact: | ||
| Priority: | high | |||
| Version: | 8.2 | CC: | jachapma, sgouvern, spichugi, tbordaz, tmihinto, vashirov | |
| Target Milestone: | rc | Keywords: | TestCaseProvided, ZStream | |
| Target Release: | 8.0 | Flags: | pm-rhel:
mirror+
|
|
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | 389-ds-1.4-8040020201120132038.866effaa | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1904145 1904349 (view as bug list) | Environment: | ||
| Last Closed: | 2021-05-18 15:45:26 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1904145, 1904349 | |||
the workaround consist in temporarily turn off the syntax check with the parameter nsslapd-syntaxcheck under cn=config with a ldapmodify command. Upstream ticket: https://github.com/389ds/389-ds-base/issues/4383 Update:
Well you found several bugs. First the crash is because a NULL pointer dereference when attempting to revert the entry cache when something goes wrong. This is a one line fix, but I will open a new bug to track that. The other issue with the escaping isa bit more complicated.
First you can delete the entry is you do this:
# ldapmodify ...
dn: cn=\ specialgroupname1,ou=groups,dc=example,dc=com
changetype: delete
If you use "/20" openldap client library will convert it to space before it reaches the server. That's a not bug in the server, and I'm not sure its a bug at all. You have have to escape it as above. What is interesting is that when you use "\ " openldap converts it to "/20". So all you have to do is just use "\ " to escape the space when deleting the entry.
But...
I then found another much more serious bug. So when you add an entry with an escaped space as the first character in the DN it is correctly put into memory (entry cache) and written to disk, but if you restart the server and try to access this entry (like trying to delete it) then the server improperly parses the index when the entry is moved into the entry cache. So the delete will work, but it does not update the entryrdn index. So trying to add the same entry back fails because the entryrdn index and id2entry are now corrupted
This is how the RDN should look:
- Raw: cn=\20specialgroupname1
- Normalized: cn= specialgroupname1
What happens is when we read the entryrdn index after a server restart, these values get normalized twice and it changes the in-memory entry to have an RDN like:
- Raw: cn= specialgroupname1
- Normalized: cn=specialgroupname1 (bad!!!!)
This also impacts reindexing, and that process also does not handle the escaped space either. So after reindexing the entry will also "disappear" from a client point of view because the RDN is incorrectly written to the entryrdn index file.
I am still working on this, but it is not a trivial fix. I have not found yet where things are breaking, but it appears to be because we normalize the RDN twice.
Fixed upstream
With build 389-ds-base-1.4.3.16-2.module+el8.4.0+8803+fd0f8fe3.x86_64
# PYTHONPATH=src/lib389/ py.test -s -v dirsrvtests/tests/suites/syntax/acceptance_test.py::test_dn_syntax_spaces_delete
re-exec with libfaketime dependencies
========================================================= test session starts ==========================================================
platform linux -- Python 3.6.8, pytest-6.1.2, py-1.9.0, pluggy-0.13.1 -- /usr/bin/python3.6
cachedir: .pytest_cache
metadata: {'Python': '3.6.8', 'Platform': 'Linux-4.18.0-249.el8.x86_64-x86_64-with-redhat-8.4-Ootpa', 'Packages': {'pytest': '6.1.2', 'py': '1.9.0', 'pluggy': '0.13.1'}, 'Plugins': {'metadata': '1.10.0', 'html': '3.0.0', 'libfaketime': '0.1.2'}}
389-ds-base: 1.4.3.16-2.module+el8.4.0+8803+fd0f8fe3
nss: 3.53.1-11.el8_2
nspr: 4.25.0-2.el8_2
openldap: 2.4.46-16.el8
cyrus-sasl: 2.1.27-5.el8
FIPS: disabled
rootdir: /mnt/tests/rhds/tests/upstream/ds/dirsrvtests, configfile: pytest.ini
plugins: metadata-1.10.0, html-3.0.0, libfaketime-0.1.2
collected 2 items
dirsrvtests/tests/suites/syntax/acceptance_test.py::test_dn_syntax_spaces_delete[props0-cn=\\20leadingSpace,ou=Groups,dc=example,dc=com] INFO:lib389.topologies:Instance with parameters {'ldap-port': 38901, 'ldap-secureport': 63601, 'server-id': 'standalone1', 'suffix': 'dc=example,dc=com'} was created.
PASSED
dirsrvtests/tests/suites/syntax/acceptance_test.py::test_dn_syntax_spaces_delete[props1-cn=trailingSpace\\20,ou=Groups,dc=example,dc=com] PASSEDInstance slapd-standalone1 removed.
========================================================== 2 passed in 17.93s ==========================================================
Marking as verified:tested
verified:tested (see comment 10) with build 389-ds-1.4-8040020201125182123.866effaa / 389-ds-base-libs-1.4.3.16-2.module+el8.4.0+8803+fd0f8fe3.x86_64 -> marking as VERIFIED 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 (389-ds:1.4 bug fix and enhancement update), 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://access.redhat.com/errata/RHBA-2021:1835 |
Description of problem: deleting the DN of a group fails if there is a leading space char in the RDN fails with error 32 user entries have a valid DN syntax with dn: uid=\ leadingspaceuser1,cn=users,dc=example,dc=test dn: uid=\20leadingspaceuser1,cn=users,dc=example,dc=test dn: cn=\ leadingspaceuser1,cn=users,dc=example,dc=test dn: cn=\20leadingspaceuser1,cn=users,dc=example,dc=test but group DNs have a different behavior: dn: cn=\ specialgroupname1,cn=groups,dc=example,dc=test dn: cn=\20specialgroupname1,cn=groups,dc=example,dc=test then, if such a group is in the database, it cannot be deleted, there is an error 32 why do the special chars cannot be escaped for groups? Version-Release number of selected component (if applicable): RHEL-8.2 389-ds-base-1.4.x but same on any versions of 389-ds-base How reproducible: on demand Steps to Reproduce: 1. have some data echo \ specialgroupname1 | base64 IHNwZWNpYWxncm91cG5hbWUxCg== echo IHNwZWNpYWxncm91cG5hbWUxCg== | base64 -d specialgroupname1 cat << EOF > ~/dn.group.cn.with.leading.space.cn.users.ldif dn: cn=users,dc=example,dc=test objectClass: top objectClass: nsContainer cn: users dn: uid=user1,cn=users,dc=example,dc=test givenName: Test sn: User1 uid: user1 cn: Test User1 displayName: Test User1 initials: TU gecos: Test User1 homeDirectory: /home/user1 uidNumber: 969400001 gidNumber: 969400001 objectClass: person objectClass: organizationalperson objectClass: posixaccount objectClass: inetorgperson objectClass: inetuser dn: uid=user2,cn=users,dc=example,dc=test givenName: Test sn: User2 uid: user2 cn: Test User2 displayName: Test User2 initials: TU gecos: Test User2 homeDirectory: /home/user2 uidNumber: 969400002 gidNumber: 969400002 objectClass: person objectClass: organizationalperson objectClass: posixaccount objectClass: inetorgperson objectClass: inetuser dn: cn=groups,dc=example,dc=test objectClass: top objectClass: nsContainer cn: groups dn: cn=\ specialgroupname1,cn=groups,dc=example,dc=test objectClass: groupofnames cn:: IHNwZWNpYWxncm91cG5hbWUxCg== description: cn with a space header char in string member: uid=user1,cn=users,dc=example,dc=test member: uid=user2,cn=users,dc=example,dc=test EOF sed -i 's/[[:space:]]*$//' ~/cn.with.a.spacegroupname.cn.groupss.ldif 2. attempt to create the goupr DN with a leading char in RDN ldapmodify -xD "cn=directory manager" -w password -caf ~/dn.group.cn.with.leading.space.cn.users.ldif Actual results: adding new entry "cn=\ specialgroupname1,cn=groups,dc=example,dc=test" ldap_add: Invalid syntax (21) adding new entry "cn=\20specialgroupname1,cn=groups,dc=example,dc=test" ldap_add: Invalid DN syntax (34) additional info: DN value invalid per syntax Expected results: yes Additional info: was reported on RHEL-6 / RHDS-9 by a customer.