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

[Simo Sorce]

On Thu, 2008-11-06 at 01:39 -0500, Simo Sorce wrote:
> 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.

Forgot another important few:

- It would make extremely difficult for people to extract this
information. Instead of connecting to a well known relational database
with well known tools used for reporting, they would have to build a
custom parser that speaks LDAP. This thing alone would be a deadly one
imo.

- The time it will take us to build all the necessary machinery around
managing such attributes (I see you even envision a plugin :-O ) would
be considerable, and would probably be much better spent on more
critical features at this stage imo. (Piping this data in a db from
python will take no more than a day or two, building schema, plugin, and
all the testing will require weeks).

Simo.

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