389-ds-base

#49132 [RFE] Allow ldap client to log specific info in DS access log
Closed: wontfix by spichugi. Opened by tbordaz.

Closed: wontfix
Reopen Issue
Issue Description

It is sometime difficult to link the ldap client logic with specific ldap operations.
For example, on a same connection a client may create new users, check access control, then do periodic searches...

It can be useful that the client provide (through specific control) a string, that is representative to own client logic/logs, and have those strings log in DS logs.

For example, string_1 and string_2

client_log:
Need to create a user (string_1)
Succeed to create the user test (string_1)
...
Try to get trust info (string_2)
...
Try to get trust info (string_3)

conn=1 op=9 SRCH base="cn=test,dc=example,dc=com" scope=0 filter="(cn=test)" attrs=ALL log_info=
conn=1 op=9 RESULT err=32 tag=101 nentries=0 etime=0 log_info=
conn=1 op=10 ADD dn="cn=test,dc=example,dc=com" log_info=
conn=1 op=10 RESULT err=0 tag=105 nentries=0 etime=0 log_info=
conn=1 op=11 DEL dn="cn=test,dc=example,dc=com" log_info=
conn=1 op=11 RESULT err=0 tag=107 nentries=0 etime=0 log_info=
conn=1 op=12 EXT oid="2.16.840.1.113730.3.8.10.4.1" name="IPA trusted domain ID mapper" log_info=
conn=1 op=13 ABANDON targetop=4 msgid=5 nentries=0 etime=6 log_info=
..
conn=1 op=20 EXT oid="2.16.840.1.113730.3.8.10.4.1" name="IPA trusted domain ID mapper" log_info=
conn=1 op=20 RESULT err=0 tag=10x etime=0 log_info=

Package Version and Platform

next release

Steps to reproduce

N/A

Actual results
Expected results

okay, with this control we need to limit length of the content provided, and what content can be provided to prevent injection attacks. Someone could add backspace chars, new lines, shell code etc. I think we should limit the identifier to alphanum only and up to 16 chars. Anything else is silently discarded.

Metadata Update from @mreynolds:
- Custom field type adjusted to defect
- Issue set to the milestone: 1.4 backlog

this is a problem of matching logs of different applications in client server relationship, it would also be a problem of ds as a client eg kerberos.
For me that is something to be discussed in the context of "common logging" and then create requirements for all the applications affected

Metadata Update from @tbordaz:
- Issue set to the milestone: 1.3.7.0 (was: 1.4 backlog)

Metadata Update from @mreynolds:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Custom field version adjusted to None
- Issue tagged with: RFE

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.4 backlog (was: 1.3.7.0)

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

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)
Metadata
None

RFE

None
None
None
None
None
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.