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

Thu Nov 6 16:13:51 UTC 2008

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.
>
> In our case we would have to implement some similar functionality but 
> in DS. That pauses a challenge.
> Here are some ideas that I wanted to run by you:
>
>   1. I do not think that it would be a good idea to keep the comments
>      separately from the entries being modified. It can be done but I
>      think it would be a database approach to solving the problem, not
>      a DS one. So I suggest that attributes that would be involved in
>      storing this information would be stored in the same entry that
>      gets modified.
>   2. If it is the same entry but there might be different kinds of
>      entries the attributes that would store comments would be combined
>      into an auxiliary object class. This way we would be able to do
>      comments on any kind of entry we want. It can be role mapping,
>      access control rule, policy or something else we do not have in
>      the system yet.

>   3. One of the important aspects of such commit log is that it should
>      be ordered can be easily orderable. It is known that multi value
>      attributes can't be ordered. So we have several options:
>         1. Use one structured attribute and stick everything into it.
>            Though it solves the problem of sorting it makes replication
>            less efficient. One and the same data will be replicated
>            over and over again.
>         2. Use dynamic number of attributes – one attribute for a
>            comment. I do not know if it is possible but even sounds
>            like a bad practice even if possible.
>         3. Use a multi value attribute. If we have a header at the
>            beginning of the mv-attribute that would have a time stamp
>            and sequence number or both, then we would be able to easily
>            sort the attribute values and present them in the right
>            order. We would also minimize replication burden and have a
>            pretty easy reporting mechanism
3.4.  OpenLDAP supports an extension by which you can create an ordered 
list of values in attributes - each value is prefixed by {N} where N is 
a number.  I think it's done in such a way that clients that understand 
ordering can request the values with the prefix, and dumb clients get 
the raw values.  Fedora DS does not support this, but perhaps we 
should?  There is an Internet Draft (or perhaps an informational RFC) 
about this feature.
>
>   4. So based on analyses above the MV approach seems like a good
>      starting point. Ok now it makes sense to enforce same behavior
>      related to this attribute(s) regardless whether one uses
>      management interface (UI/CLI) or direct LDAP calls. This means
>      that all the logic related to our commit log object class should
>      be handled via DS plugin.
>   5. Let us list the operations that the DS should support against the
>      attribute(s) that would store the commit log data:
>
> Add: Add a new comment to the end of the list (low level privilege 
> operation)
> Modify: Change comment in the list (high level privilege operation)
> Delete: Comment from the list (high level privilege operation)
> List: Return all entries sorted the order they have been added. (low 
> level privilege operation)
> Get: Get specific item from the list by some sort of identifier – 
> needed to be able to modify/replace the right comment. (low level 
> privilege operation)
> If we do not allow modification of the list then we do not need 
> “modify”, “delete” and “get” operations. Is this acceptable? Then it 
> would be much simpler to create a DS plugin that will just respond to 
> add, and search requests and would reject attempts to delete or modify 
> value. One would be able to delete the whole entry though.
>
>   6. The value would be structured like this:
>         1. sequence number (integer as string left zero padded to 10
>            characters)
>         2. length of user CN as left zero padded 4 digit string
>         3. user CN of the user who created a comment
>         4. time stamp of creation in YYYYMMDDHHMMSS in UTC
>         5. time stamp of last modification in YYYYMMDDHHMMSS in UTC
>         6. comment itself
>      Since the size of the items is fixed or can be easily determined
>      we do not need any separators thus there is no need to escape
>      anything in data itself.
>   7. To be able to efficiently maintain the list we would need another
>      attribute. This attribute will contain a current max sequence
>      number. That attribute would be updated each time a new comment is
>      added to the list. The plugin will control access to it and
>      prevent any direct modification of this attribute.
>   8. In future is we decide to change the format we would be able to
>      add other attributes that would contain a version or a format
>      specifier. The logic of the plugin would then be changed to check
>      those attributes and if they are not present it will fall back to
>      original (this format). So I do not see a need to add any format
>      or version attribute in the first implementation.
>   9. The ldap search will return all the values of the mv-attribute
>      already sorted. It would be a responsibility of the caller to
>      parse parts of it out and present the information to the user in a
>      usable format.
>
> Any ideas or comments or suggestions are appreciated.
This sounds a lot like the information we keep in the replication 
changelog, and to a certain extent the replication state information we 
keep in the entry itself.  Also in the retro changelog.

If we were to do something like this, it would be worth revisiting the 
current internal change notification code that we use in various places 
(post ops, persistent search, replication changelog, retro changelog, 
audit log, etc.) so that we could have a general purpose internal change 
notification service to be used by all of these various "sinks" and more.
>
> Thank you
> Dmitri
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel