Hide Forgot
Description of problem: the function check_trivial_words is failing to recongnize a token that is exactly same size as the token length. Example: dn: uid=Dord,ou=People,dc=parente,dc=local sn: David objectClass: top objectClass: account objectClass: posixaccount objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person uid: Dord cn: David loginShell: /bin/bash homeDirectory: /home/dorda uidNumber: 501003 gidNumber: 510003 passwordMinTokenLength: 4 ldapmodify -D "uid=Dord,ou=People,dc=parente,dc=local" -w secret12 dn: uid=Dord,ou=People,dc=parente,dc=local changetype: modify replace: userpassword userPassword: dord modifying entry "uid=Dord,ou=People,dc=parente,dc=local" Actual results the password including a token of 4 length is accepted (it's the exact length of the attribute). Version-Release number of selected component (if applicable): 389-ds-base-1.3.6.1-21 How reproducible: always Actual results: password is not refused. Expected results: password refused when the token length is same length than the attribute. Additional info: After some debugging, the function: check_trivial_words calls ldap_utf8prevn(sp, ep, toklen); This function returns NULL when the token length is same length than the attribute value in "sp". IMHO, this should be the fix: char ldap_utf8prevn(char s, char from, int n) { char prev = from; if (!s || !from || (s > from)) { return NULL; } for (; n > 0; --n) { prev = ldap_utf8prev(prev); if ((prev <= s) && (n > 0)) { <============= should be (prev < s) return NULL; } } return prev; } For instance, in the previous example, ldap_utf8prevn("dord", char *from,4) will loop to find the postfix d, rd, ord, and will return NULL for dord. So check_trivial_words will fail to refuse the password.
Investigating, but German you told me in a meeting that would found another issue when the token length is set higher than 6 (or something like that). Can you elaborate on this other issue you found?
Upstream ticket: https://pagure.io/389-ds-base/issue/49524
Fixed upstream
============================================================================ test session starts ============================================================================ platform linux -- Python 3.6.3, pytest-3.4.0, py-1.5.2, pluggy-0.6.0 -- /opt/rh/rh-python36/root/usr/bin/python3 cachedir: .pytest_cache metadata: {'Python': '3.6.3', 'Platform': 'Linux-3.10.0-845.el7.x86_64-x86_64-with-redhat-7.5-Maipo', 'Packages': {'pytest': '3.4.0', 'py': '1.5.2', 'pluggy': '0.6.0'}, 'Plugins': {'metadata': '1.5.1', 'html': '1.16.1'}} 389-ds-base: 1.3.7.5-18.el7 nss: 3.34.0-4.el7 nspr: 4.17.0-1.el7 openldap: 2.4.44-13.el7 svrcore: 4.1.3-2.el7 rootdir: /mnt/tests/rhds/tests/upstream/ds/dirsrvtests/tests/suites/password, inifile: plugins: metadata-1.5.1, html-1.16.1 collected 1 item pwdPolicy_token_test.py::test_token_lengths OK group dirsrv exists OK user dirsrv exists INFO:lib389.topologies:Instance with parameters {'ldap-port': 38901, 'ldap-secureport': 63601, 'server-id': 'standalone1', 'suffix': 'dc=example,dc=com'} was created. INFO:dirsrvtests.tests.suites.password.pwdPolicy_token_test:Testing password len 4 token (test) INFO:dirsrvtests.tests.suites.password.pwdPolicy_token_test:Password correctly rejected: {'desc': 'Constraint violation', 'info': 'invalid password syntax - password based off of user entry'} INFO:dirsrvtests.tests.suites.password.pwdPolicy_token_test:Testing password len 6 token (test_u) INFO:dirsrvtests.tests.suites.password.pwdPolicy_token_test:Password correctly rejected: {'desc': 'Constraint violation', 'info': 'invalid password syntax - password based off of user entry'} INFO:dirsrvtests.tests.suites.password.pwdPolicy_token_test:Testing password len 10 token (test_user1) INFO:dirsrvtests.tests.suites.password.pwdPolicy_token_test:Password correctly rejected: {'desc': 'Constraint violation', 'info': 'invalid password syntax - password based off of user entry'} PASSEDInstance slapd-standalone1 removed. ========================================================================= 1 passed in 12.40 seconds =========================================================================
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://access.redhat.com/errata/RHBA-2018:0811