389-ds-base

#50027 Ticket 50026 - audit logs does not capture the operation where nsslapd-lookthroughlimit is modified
Closed by spichugi. Opened by tbordaz.
tbordaz/389-ds-base ticket_50026  into  master

Download 50027.patch

Bug Description:
During a dse update (config, schema,..) the dse callback will process the mods
but can also modify them (SLAPI_MODIFY_MODS) leaving only ignored attributes.
A consequence is that later audit logging will only log the ignored attributes.

Fix Description:
Save a copy of the orignal mods before the dse callback and restore them
when dse callback completes.

https://pagure.io/389-ds-base/issue/50026

Reviewed by: ?

Platforms tested: F27

Flag Day: no

Doc impact: no

this will ensure we log the mods we receive in the audit log, but I have two remarks:

1) if mods can be removed and ignored we do not see this in the audit log, do we somewhere specify if it should log the received or the applied mods?

2) what about mods on "real" backends, we have the case where otp plugin can remove mods, are they seen in the audit log, if not should they be ? We should be consistent.

@lkrispen thanks for the review and sorry for my late answer. To be honest I found difficult to understand the logic of that part of code :(

1) audit logging records all the changes that are present in the mods after the postop. At this point it did not know which of them were received or not and even if they were applied or not. It just drop mod that have invalid MOD type.

For DSE update, the fix logs the received mods. It logs all the mods the dse backend (ldbm config) applied but if an other mod (not processed by dse backend) is later removed in the preop, it will log it.

Reading the code, I found it complex and error prone. For example I think that if a MOD fails after the dse_callback, the updates processed in dse_callback are not undone. So the ldbm config entry may not reflect what is configured in the database.

2) OTP plugin can removes mods (prevent counters going backward) before applying on the backend.
DSE preop removes mods that it actually applies on the backend (ldbm config) and ignores (i.e. leave) mods that it does not know how to handle (modifiersname, modifytimestamp...).
So mods logged by DSE were not consistent with the other backends as it did not log the mods it applied.

thanks for the explanation.

ack

rebased onto a1578a9bce9cec3a6f459e621e2a12be7dcacfcc

Pull-Request has been merged by tbordaz

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 pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3086

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.

Pull-Request has been closed by spichugi
Metadata
None
No Tags
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.