Improve logging of ACL decisions

[389-ds-bot]

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/47822

• Created at 2014-06-23 14:37:45 by abbra
• Assigned to lkrispen (@elkris)
• Associated bugzillas
  • https://bugzilla.redhat.com/show_bug.cgi?id=1208608

---

ACL plugin is painfully to debug as it doesn't give you any reason why decision was made.

Actually, it has internal logging of these decisions but the messages are suppressed when 389-ds is compiled on platforms where TNF library is not available.

However, the code in ACL plugin doesn't really use much of TNF functionality that couldn't be emulated with plain preprocessor magic.

Enable logging using slapi_log_error() for non-TNF case.

[389-ds-bot]

Comment from abbra at 2014-06-23 14:38:59

Attached is a prototype patch.

[389-ds-bot]

Comment from lkrispen (@elkris) at 2014-06-23 16:17:41

attachment
0001-Define-TNF-compatible-ACI-logging-for-non-TNF-enviro.patch

[389-ds-bot]

Comment from abbra at 2014-06-23 19:13:28

attachment
0001-Define-TNF-compatible-logging-for-non-TNF-environmen.patch

[389-ds-bot]

Comment from abbra at 2014-06-23 19:16:06

I've uploaded my version which is very similar to what Ludwig did but avoids pulling in formatting string into formatting string, i.e. avoids having

  foo = sprintf("%s", tnf_string);
  bar = sprintf(foo, data);

because this is a potential issue that is now detected by Fedora scripts.

[389-ds-bot]

Comment from lkrispen (@elkris) at 2014-06-23 20:46:54

ok, but I think we should have another log level, otherwise there will be surprises if acl loggin is logging much more than before.
Another question is, could this TNF -> logging transformation be useful in other places as well ?
Or could we remove this solaris specific feature and do normal logging ?

[389-ds-bot]

Comment from abbra at 2014-06-23 20:54:15

Both approaches would work for me.

In ACL plugin I specifically interested in getting information what caused evaluation to fail or to allow. These are currently displayed in TNF logging, especially in TestRights and not available on either level via normal slapi_log_error() calls.

[389-ds-bot]

Comment from nhosoi (@nhosoi) at 2015-04-02 22:38:11

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1208608

[389-ds-bot]

Comment from nhosoi (@nhosoi) at 2015-04-02 22:38:26

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1208609

[389-ds-bot]

Comment from nhosoi (@nhosoi) at 2015-04-02 22:41:25

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1208610

[389-ds-bot]

Comment from lkrispen (@elkris) at 2016-01-14 19:28:34

Looking again into the TNF calls I am no longer convince that just replacing the TNF macros by calls to slapi_log_error is useful. The original use of TNF is to log traces about execution and so there are many calls just loging enter and exit of a function, this would blow up the volumnious acl logging even more and giv eno extra benefit.
The exception id in TestRights, since TNF is called at any return, and there are many places to return from TestRights this could give more information on the reason TestRights did decide to allow or deny acces.

I suggest not to automatically convert TNF calls into logging, but add more dedicated messages in TestRights, and check if there are other places, not yet covered by TNF or normal logging, which could be helpful.

maybe we close this ticket and open a new one.

[389-ds-bot]

Comment from lkrispen (@elkris) at 2016-01-15 20:08:47

changed subject according to latest comment

[389-ds-bot]

Comment from abbra at 2017-02-11 22:55:30

Metadata Update from @abbra:

• Issue assigned to elkris
• Issue set to the milestone: 1.3.7 backlog

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2019-08-23 21:18:59

Metadata Update from @mreynolds389:

• Custom field reviewstatus adjusted to None
• Issue close_status updated to: None
• Issue set to the milestone: 1.4 backlog (was: 1.3.7 backlog)

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2020-05-20 16:47:29

Metadata Update from @mreynolds389:

• Issue set to the milestone: 1.4.5 (was: 1.4 backlog)
• Issue tagged with: Access Control, RFE