[Freeipa-devel] "Commit comments log" functionality in IPA

[Simo Sorce]

On Wed, 2008-11-05 at 19:14 -0500, Dmitri Pal wrote:
> Hello,
> 
> One of the ideas that we are exploring for IPA v2 is to have sort of 
> “commit comment” feature. The examples of the use cases are:
> * Administrator changed and pushed out the policy. As he saves it or 
> applies it (pushes it) he will be prompted to make a comment mainly 
> describing why the operation was performed.
> * Administrator changed mapping of the users and hosts to a role. He is 
> prompted to make a comment about the operation he performed.
> * Administrator changed host based access control rule. Same thing as 
> above.
> 
> These are just several examples of where the commenting on the operation 
> performed might be very important for audit purposes.
> The main differentiator between the logging of different activity and 
> such feature is that it allows administrator to leave some tips, reasons 
> and answers to questions “why this or that operation was performed and 
> why it was done this way”. We believe that having such functionality 
> would be very valuable for IPA customers.
> 
> Bugzilla bug has a very similar functionality. It records not only 
> comments themselves, but who left the comment and when. It also allows 
> modifying comments later on. I have seen the implementations where the 
> comments can't be modified but just added.

Up to here I follow you, and I think some users would find somewhat
useful to have some sort of process management around high level UI
functions.
I am not sure a mandatory comment on most operations would be welcome, I
think most Admins would just hate such a feature, as it would get in the
way of their job, this unless, perhaps, it pops up only once per "macro"
operation.
If it is not mandatory admins will simply skip it.

Suppose Admin A has to change some 20 policies to fix a minor policy
bug. If you ask him once to leave a comment, he may grumble, but he
would probably do it. If you ask him to leave a comment for each of the
20 policies, he would probably A) throw the keyboard at the monitor
after the 3rd one, B) try to find and kill us :), C) post the following
comment for all changes: "asdfg".

> In our case we would have to implement some similar functionality but in 
> DS. That pauses a challenge.

Ok, here I don't follow you anymore. It's understandable to have audit
trails on some operations, but why would we want to store them in DS ??

Can you provide what are the reasons that would make a good idea to
store this kind of data in DS instead of a log file or a log database ?

I honestly see no reason, nothing but a human operator would make any
use of such attributes, they are not useful to any machine which is the
real consumer of DS data.
As you pointed on it would add an unnecessary amount of data to
replicate around.

Also because DS is not a logging server but a directory server there are
many other problems in trying to use it to store logs.


So, while I may agree that some kind of commenting feature could be
useful, I really do not see at all DS as the right storage for this
stuff. Far from.

If comments are required for audit trails I think they should just go in
the auditing system and marked as special "comment" logs. Otherwise they
should probably simply go in a normal log file or a relational log
database (the latter in case online searches are required).


Now to some of the reasons why I don't see DS as a viable option:

- Multi-value attributes are not ordered, so you need to invent some
scheme to store this data structured so that ordering can be preserved.
Sure probably using the "posting" date before the content is all is
needed, but that makes attributes not searcheable.

- You would have to create a clean up process that removes old stuff, I
don't think that keeping around a hundred entries log for years would
make sense.

- We would need to index yet another attribute if you want to make
searches on it, note also that just consulting the log would require
searches on the identity store increasing its load, something a log
file/database would avoid completely.

- If you invent a complex format you loose the capability to do decent
filtering on searches, meaning you will often need to do wide scope
searches and implement filtering in the UI (slooow, and loads DS)

- You have no relation of events (ldap not beeing a relational database
makes it particularly difficult indeed).

- If a single UI command changes many different objects, where do you
store the comment? In one? All of them?
If in one how do you relate changes to others ?
If you replicate it an all objects how do you deal with access to all
entries? (see below)
See also scenario above about angry admins if you require a comment for
each object being changed.

- Comments may contain sensitive information that should not be leaked,
so comments should not me generally available for search on ldap.
This would require to add (on the fly?) ACIs on objects that get
comments.

- Some ACI may allow a lower level admin to perform an operation on some
attributes, but not add objectclasses or new attributes.
We loose the comments in this case ?

- Anyone with write access to the attribute will be able to change the
contents, making them generally completely useless as audit trails.
Delegation of any minor task would require write access to comments all
over the place.

Simo.

P.S: please remove the reply-to if you want replies to go to the mailing
list by default :-)

-- 
Simo Sorce * Red Hat, Inc * New York