Please add the steps to reproduce the problem.
command-line with test data
actual result
* expected result

OS and 389-ds-base version you used for the test?

anjain@redhat.com wrote:

How do I find out the 389-ds-base version that I used?
If it is on your local build, you could note the git branch.
But in the case, you should repeat the test without your local change (if any),
otherwise we cannot eliminate the possibility that your local fix introduced
the problem.

Replying to [comment:1 nhosoi]:

Please add the steps to reproduce the problem.
command-line with test data
actual result
* expected result

OS and 389-ds-base version you used for the test?
Tested with master branch on Fedora18

Steps to reproduce:

Command line: ldapadd -x -D "cn=directory manager" -w password -f test.ldif

Contents of test.ldif:

dn: uid=Testuser1,ou=People,dc=localdomain
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Testuser1
sn: user1
uid: Testuser1
givenName: Test
userPassword: κñόσμε

Actual output: New user added

Expected output: ldap_add: Constraint violation (19)
additional info: The value is not 7-bit clean: κñόσμε

Don't change the API of bit_check. Rather, adjust the data (clear text password string in this case) to the API.

In both preop_add and preop_modify, you could create "struct berval" from the clear text password you retrieved from entry 'e' using slapi_get_first_clear_text_pw. And pass it to the second argument of bit_check.

To create "struct berval", the easiest way would be like this:
struct berval *vals[2];
struct berval val;
vals[0] = &val;
vals[1] = NULL;
val.bv_val = clear_text_password;
val.bv_len = strlen (val.bv_val);

Also, the password returned from slapi_get_first_clear_text_pw needs to be freed by the caller.
{{{
/
* The returned string is a copy.
* Caller must free it.
/
char slapi_get_first_clear_text_pw(Slapi_Entry entry)
}}}
Please run valgrind against your local server.

Replying to [comment:5 nhosoi]:

Don't change the API of bit_check. Rather, adjust the data (clear text password string in this case) to the API.

In both preop_add and preop_modify, you could create "struct berval" from the clear text password you retrieved from entry 'e' using slapi_get_first_clear_text_pw. And pass it to the second argument of bit_check.

To create "struct berval", the easiest way would be like this:
struct berval *vals[2];
struct berval val;
vals[0] = &val;
vals[1] = NULL;
val.bv_val = clear_text_password;
val.bv_len = strlen (val.bv_val);

done

Also, the password returned from slapi_get_first_clear_text_pw needs to be freed by the caller.
{{{
/
* The returned string is a copy.
* Caller must free it.
/
char slapi_get_first_clear_text_pw(Slapi_Entry entry)
}}}
Please run valgrind against your local server.
done

Modify case, once 'pwd' is set (non-NULL), the rest of the to-be-checked attribute values won't be passed to bit_check? E.g., is this correctly rejected?
$ ldapmodify ... << EOF
dn: ...
changetype: modify
replace: userpassword
userpassword: <ascii string>
-
replace: mail
mail: <non-ascii string>
EOF

Replying to [comment:9 nhosoi]:

Modify case, once 'pwd' is set (non-NULL), the rest of the to-be-checked attribute values won't be passed to bit_check? E.g., is this correctly rejected?
$ ldapmodify ... << EOF
dn: ...
changetype: modify
replace: userpassword
userpassword: <ascii string>
-
replace: mail
mail: <non-ascii string>
EOF
Fixed the problem

You set NULL to pwd if bit_check returns 0 (SUCCESS), which is okay to go to the next loop to check more attributes. But it makes pwd leak since this won't free the allocated memory for pwd once NULL is set to pwd.
{{{
355 slapi_ch_free_string(&pwd);
}}}
Not to lose the address of the pwd, please keep it somehow. And free the memory using the backup.
{{{
221 char pwd = NULL;
22? char origpwd = NULL;
...
302 origpwd = pwd = slapi_get_first_clear_text_pw(e);
...
355 slapi_ch_free_string(&origpwd);
}}}

7-bit check plugin userpassword validation fix
0001-Ticket-47423-7-bit-check-plugin-does-not-work-for-us.patch

Reviewed by Noriko (Thank you!!)

Pushed to master: commit d804aaf

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1044147

Pushed to 389-ds-base-1.3.1:
e50653f..f5ee5b8 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
commit f5ee5b8babfb7b61db7da3db7ab7c443eda58323

Pushed to 389-ds-base-1.2.11:
b4248f8..7e7a85f 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit 7e7a85f

Reverted from 389-ds-base-1.2.11:
ef7473d..fc67fb8 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit fc67fb8
Revert "Ticket #47423 - 7-bit check plugin does not work for userpassword attribute"

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/760

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.