When audit logging is enabled on Red Hat Directory Server and 389 Directory Server, changes to cn=config:nsslapd-rootpw result in the password value being logged in cleartext. The audit log records an entry similar to the following: dn: cn=config changetype: modify replace: nsslapd-rootpw nsslapd-rootpw: secret User passwords, however, are not logged verbatim but in hashed form. Although the directory server administrator can configure the path and permissions of the audit log, by default it is mode 0600, owned by the directory server user, and is located in the directory server log directory (/var/log/dirsrv/slapd-[hostname]), which is mode 0770 and owned by the directory server user ("nobody", by default)
Created attachment 463525 [details] Patch Patch reviewed by richm and pushed to master. Counting objects: 11, done. Delta compression using up to 2 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 1.56 KiB, done. Total 6 (delta 4), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 23e2856..d38ae06 master -> master
1. time: 20110520184940 dn: cn=config changetype: modify replace: nsslapd-auditlog-logging-enabled nsslapd-auditlog-logging-enabled: on - replace: modifiersname modifiersname: cn=directory manager - replace: modifytimestamp modifytimestamp: 20110520131940Z - time: 20110520185059 dn: cn=config changetype: modify replace: nsslapd-rootpw nsslapd-rootpw: {SSHA}PATXAhi/wSSlaJABfT3EJFNuZdjfE94/PhF4FA== - replace: modifiersname modifiersname: cn=directory manager - replace: modifytimestamp modifytimestamp: 20110520132059Z 2. [root@testvm scripts]# ls -l /var/log/dirsrv/slapd-testvm/audit -rw-------. 1 nobody nobody 522 May 20 18:51 /var/log/dirsrv/slapd-testvm/audit 3. [root@testvm scripts]# ls -l /var/log/dirsrv/ total 8 drwx------. 2 nobody nobody 4096 May 20 15:18 admin-serv drwxrwx---. 2 nobody nobody 4096 May 20 18:52 slapd-testvm
This issue should be resolved now, yes? So we can close this bug?
(In reply to comment #7) > This issue should be resolved now, yes? So we can close this bug? Yes, and yes.
Fantastic, thanks!