RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 834053 - [RFE] Plugins - ability to control behavior of modifyTimestamp/modifiersName
Summary: [RFE] Plugins - ability to control behavior of modifyTimestamp/modifiersName
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base
Version: 6.4
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Sankar Ramalingam
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-20 17:58 UTC by Nathan Kinder
Modified: 2020-09-13 19:52 UTC (History)
5 users (show)

Fixed In Version: 389-ds-base-1.2.11.15-4.el6
Doc Type: Enhancement
Doc Text:
Feature: Control of modifiersname Reason: If a user made an update that triggered a plugin to make another update, the modifersname would always bethe plugin. Result (if any): If configured, the modifiersname would be the user that initiated the operation, and a new attribute internalmodifiersname will still record the plugin dn.
Clone Of:
Environment:
Last Closed: 2013-02-21 08:18:28 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 111 0 None closed Plugins - ability to control behavior of modifyTimestamp/modifiersName 2021-01-22 12:56:04 UTC
Red Hat Product Errata RHSA-2013:0503 0 normal SHIPPED_LIVE Moderate: 389-ds-base security, bug fix, and enhancement update 2013-02-21 08:18:44 UTC

Description Nathan Kinder 2012-06-20 17:58:58 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/111

https://bugzilla.redhat.com/show_bug.cgi?id=453756

{{{
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9)
Gecko/2008052906 Firefox/3.0

Description of problem:
It would be a nice feature (for example, some additional functions in the
plug-in API) that the plugins could execute internal modification operations
without changing the operational attributes (modifiersName, modifyTimestamp
etc).

It would greatly simplify the management of an LDAP infrastructure in case
there are many admins and unit managers - one could see right away who was the
last person to change the entry. Today in our production environment we have to
write and stock full audit logs to follow these changes.

The problem is that each time an internal plug-in modifies the entry (in
particular it concerns the referential integrity and memberOf plugins in our
production environment) the modifiersName is changed to the plug-in
configuration DN (and the attribute modifyTimestamp accordingly).

Version-Release number of selected component (if applicable):


How reproducible:
Always


Steps to Reproduce:
1. Make a modification that concerns a plug-in like memberOf or referential
integrity.


Actual Results:
Take a look at the attributes modifiersName and modifyTimestamp. Even if we
have not DIRECTLY changed the entry we will find these attributes changed.
Example :

nscpentryWSI: creatorsName: uid=andrey.ivanov,ou=person...
nscpentryWSI: modifiersName: cn=MemberOf,cn=plugins,cn=config
nscpentryWSI: createTimestamp: 20070803092138Z
nscpentryWSI: modifyTimestamp: 20080419154554Z


Expected Results:
An option should allow to avoid touching the modifiersName and modifyTimestamp
by internal plug-in modification operations.

Additional info:
This is not a bug, it is a feature request. It is linked in a certain way to
the bug 434914.
}}}

Comment 1 RHEL Program Management 2012-07-10 06:17:34 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 2 RHEL Program Management 2012-07-10 23:01:39 UTC
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Comment 4 Amita Sharma 2012-10-18 17:16:51 UTC
Found an issue while testing DNA plugin for this RFE.
Steps::
1. Set nsslapd-plugin-binddn-tracking attribute is ON
2. Enable DNA plugin
3. Add a test entry which should take next dna value for its uidnumber
4. Check the internelModifier name for the test entry, It should be plugin DN

/usr/lib64/mozldap/ldapsearch -1 -h dhcp201-134.englab.pnq.redhat.com -p 22594 -D cn=directory manager -w Secret123 -b cn=Posix User1,dc=example,dc=com objectClass=* internalModifiersname | grep cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
internalModifiersname is not plugin DN

But as in above ldapsearch, we are not getting plugin DN and instead we are getting UserDN.

Which is may be due to "ticket 302 superseded ticket 111".

Reopening the bug.

Comment 6 mreynolds 2012-11-08 12:59:23 UTC
memberOf does not create entries, so internalCreatorsname is not used.

Comment 7 mreynolds 2012-11-12 14:16:39 UTC
Also, if there is no internalCreatorsname, then that entry was probably created before turning on nsslapd-plugin-binddn-tracking.

Comment 8 Noriko Hosoi 2012-11-17 01:12:24 UTC
Bug fix for this RFE bug is added to the build 389-ds-base-1.2.11.12-4.el6:
Ticket #495 - internalModifiersname not updated by DNA plugin

Comment 9 Nathan Kinder 2012-11-26 17:13:43 UTC
The previous comment had a typo in the version number.  The correct package where the latest fix exists is 389-ds-base-1.2.11.15-4.el6.

Comment 13 Amita Sharma 2013-01-04 11:28:29 UTC
Test cases are automated and all are passed.
So marking the bug as VERIFIED.

Comment 15 errata-xmlrpc 2013-02-21 08:18:28 UTC
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.

http://rhn.redhat.com/errata/RHSA-2013-0503.html


Note You need to log in before you can comment on or make changes to this bug.