On Monday, March 10, 2014 05:48:06 PM Steve Grubb wrote:
Hello,
I was looking at a new kernel and see that the audit_status structure has
changed. The first member of the structure is a bit mask that tells what all
is in the structure. So, if we add this:
__u32 version; /* audit api version number */
__u32 backlog_wait_time;/* message queue wait timeout */
};
Then we need to have a define for those two:
#define AUDIT_STATUS_BACKLOG_LIMIT 0x0010
+#define AUDIT_STATTUS_VERSION 0x0020
-#define AUDIT_STATUS_BACKLOG_WAIT_TIME 0x0020
+#define AUDIT_STATUS_BACKLOG_WAIT_TIME 0x0040
IOW, each entry in the structure is supposed to have a mask value.
Actually, I think the problems are worse. We have the issue of an expanding
data structure over time as new things get added. But yet we have a fixed sized
audit_status structure. I could copy that into the audit package's source code
so that I have the new structure definition. But I will have to do the same
thing each time. Also, how would an old kernel tolerate a bigger audit_status
structure being sent with AUDIT_SET commands by a new auditctl?
What we should do is leave AUDIT_GET the way it was. We should then define
AUDIT_GET_EXT and then use it a lot like audit_rule_data which has
struct audit_status_ext {
__u32 field_count;
__u32 fields[AUDIT_MAX_FIELDS];
__u32 values[AUDIT_MAX_FIELDS];
};
Then insert the field identifier in fields and the value in the other. This way
the format is defined once and we can reuse it for a long time.
From user space, the migration would be easy. Old auditctl still uses
AUDIT_GET. New auditctl would try AUDIT_GET_EXT and if that's not recognized,
drop back to AUDIT_GET. Then one day down the road we remove AUDIT_GET in the
kernel.
This is how we did the migration from AUDIT_RULES to AUDIT_RULES_DATA.
-Steve