so I finally found what's the problem.

I run openldap in chroot. In Solaris, function lutil_entropy() uses /dev/urandom (if configure script finds it which is my case) to generate random strings for salt. Since in chroot it was not able to open /dev/urandom since it was not existent in chroot jail and there is no any error message loged in the lutil_entropy() when open() returns value <0. it simply returns up to calling function. Once I mknod dev/urandom in chroot everything started to work properly.

So it is definately not the bug nor is it compiler flaw.

Not sure if it's required by coding standards but I would log some informative message if function fails to open a device apart from very generic "implementation specific" message.

Thanks all for help,

/M.

ando@sys-net.it wrote:

mariusp44@gmail.com wrote:

...

sorry, if I was misunderstood. I am not asking to do my legwork. Just trying to understand what is going wrong. Sorry, if it seemed that way.

I installed Sun Studio 12 (latest) and the problem is the same. I don't think Sun Studio is not working compiler. Just looks very unlikely. IT compiles everything without single problem. both 32 and 64 bit memory models.

Perhaps I was not entirely clear. Weird thing is that it is only not working when changing password using ldappasswd and hash is set to SMD5 SSHA or CRYPT. If I manually change the password setting userPassword after generating it with slappasswd using say SSHA, it works fine. I mean user can bind using password that is stored in SSHA or SMD5. That tells me that slapd can still do encryption properly and check against hashes in question. At some point it needs to generate a hash and does it properly. Only when slapd is asked to change a password with ldappasswd it is unable to generate proper hash. Unless process is entirely different when changing password and authorizing against password. I am not insisting it is a bug in slapd code. But I am running out of ideas what else could be wrong and was just hoping that somebody else is using openldap on the same architecture and perhaps experienced something similar.

Since no one else is seeing the problem, I already recommended that you step in the (non-optimized) code with a debugger and see why this happens. The right place to start is slap_passwd_hash_type(), whose failure is setting the error message you see.

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it

---

Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it

---