Bug 1335492
| Summary: | Modifier's name is not recorded in the audit log with modrdn and moddn operations | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Punit Kundal <pkundal> |
| Component: | 389-ds-base | Assignee: | Noriko Hosoi <nhosoi> |
| Status: | CLOSED ERRATA | QA Contact: | Viktor Ashirov <vashirov> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.3 | CC: | nhosoi, nkinder, rmeggins |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 389-ds-base-1.3.5.5-1.el7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-11-03 20:41:59 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: | |||
|
Description
Punit Kundal
2016-05-12 10:22:09 UTC
Upstream ticket: https://fedorahosted.org/389/ticket/48834 The change type recorded in the audit log for moddn operation on an entry is modrdn, here are the steps performed: 1. Modified the dn of the entry [root@ds ~]# ldapmodify -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389 dn: uid=testuser,ou=People,dc=example,dc=com changetype: moddn newrdn: uid=tuser deleteoldrdn: 1 newsuperior: ou=Groups,dc=example,dc=com modifying rdn of entry "uid=testuser,ou=People,dc=example,dc=com" As can be seen, I've changed the rdn of the entry as well the the subtree to which it belongs. 2. Checked the audit log file [root@ds ~]# tail -f /var/log/dirsrv/slapd-supplier/audit time: 20160623153022 dn: uid=testuser,ou=People,dc=example,dc=com result: 0 changetype: modrdn #The change type is modrdn newrdn: uid=tuser deleteoldrdn: 1 newsuperior: ou=Groups,dc=example,dc=com modifiersname: cn=directory manager Is this correct? It's an easy fix. Reopening a bug...
diff --git a/ldap/servers/slapd/auditlog.c b/ldap/servers/slapd/auditlog.c
index 0f4cc94..4605ae5 100644
--- a/ldap/servers/slapd/auditlog.c
+++ b/ldap/servers/slapd/auditlog.c
@@ -330,7 +330,7 @@ write_audit_file(
case SLAPI_OPERATION_MODDN:
newrdn = ((char **)change)[0];
addlenstr( l, attr_changetype );
- addlenstr( l, ": modrdn\n" );
+ addlenstr( l, ": moddn\n" );
addlenstr( l, attr_newrdn );
addlenstr( l, ": " );
addlenstr( l, newrdn );
Sorry, let me take back my previous comment #c5. The changetype moddn is an alias of modrdn. So, the server does not distinguish them. Internally, there is only one operation which is MODRDN (e.g., the following log messages are from the access log. So, please ignore the difference in the audit log, too. dn: uid=tuser0,ou=People,dc=example,dc=com changetype: modrdn newrdn: uid=tuser00 deleteoldrdn: 1 [..] conn=6 op=1 MODRDN dn="uid=tuser0,ou=People,dc=example,dc=com" newrdn="uid=tuser00" newsuperior="(null)" [..] conn=6 op=1 RESULT err=0 tag=109 nentries=0 etime=0 dn: uid=tuser00,ou=People,dc=example,dc=com changetype: moddn newrdn: uid=tuser000 deleteoldrdn: 1 [..] conn=8 op=1 MODRDN dn="uid=tuser00,ou=People,dc=example,dc=com" newrdn="uid=tuser00" newsuperior="(null)" [..] conn=8 op=1 RESULT err=0 tag=109 nentries=0 etime=0 Thanks. DS builds: 389-ds-base-1.3.5.6-1.el7.x86_64 389-ds-base-libs-1.3.5.6-1.el7.x86_64 Following are the steps performed for verification: 1. Enabled audit logging on a standalone DS instance [root@ds ~]# ldapmodify -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389 dn: cn=config changetype: modify replace: nsslapd-auditlog-logging-enabled nsslapd-auditlog-logging-enabled: on modifying entry "cn=config" 2. Added a user entry [root@ds ~]# ldapadd -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389 dn: uid=tuser,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: inetOrgPerson uid: tuser cn: test user sn: user adding new entry "uid=tuser,ou=People,dc=example,dc=com" 3. Modified the rdn of the entry [root@ds ~]# ldapmodify -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389 dn: uid=tuser,ou=People,dc=example,dc=com Changetype: modrdn newrdn: uid=testuser deleteoldrdn: 1 modifying rdn of entry "uid=tuser,ou=People,dc=example,dc=com" 4. Checked the audit log file [root@ds ~]# tail -f /var/log/dirsrv/slapd-supplier/audit time: 20160623152639 dn: uid=tuser,ou=People,dc=example,dc=com result: 0 changetype: modrdn newrdn: uid=testuser deleteoldrdn: 1 modifiersname: cn=directory manager 5. Modified the dn of the entry [root@ds ~]# ldapmodify -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389 dn: uid=testuser,ou=People,dc=example,dc=com changetype: moddn newrdn: uid=tuser deleteoldrdn: 1 newsuperior: ou=Groups,dc=example,dc=com modifying rdn of entry "uid=testuser,ou=People,dc=example,dc=com" 6. Checked the audit log file [root@ds ~]# tail -f /var/log/dirsrv/slapd-supplier/audit time: 20160623153022 dn: uid=testuser,ou=People,dc=example,dc=com result: 0 changetype: modrdn newrdn: uid=tuser deleteoldrdn: 1 newsuperior: ou=Groups,dc=example,dc=com modifiersname: cn=directory manager 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://rhn.redhat.com/errata/RHSA-2016-2594.html |