offsets for 64bit IPC mechanisms

Hello,

BZ 221663 was opened to report a problem with some test results. From the bugzilla:

semctl(id, 0, IPC_RMID);
Expected argument: a0 = SEMCTL, a1 = id, a2 = 0, a3 = 0 (IPC_RMID) Actual arguments seen in the audit log: a0 = SEMCTL, a1 = id, a2 = 0, a3 = 0x100

msgctl(id, IPC_STAT, &buf)
Expected argument: a0 = MSGCTL, a1 = id, a2 = 2 (IPC_STAT) Actual arguments seen in the audit log: a0 = MSGCTL, a1 = id, a2 = 0x102

The answer was:

/*
* Version flags for semctl, msgctl, and shmctl commands
* These are passed as bitflags or-ed with the actual command */
#define IPC_OLD 0 /* Old version (no 32-bit UID support on many
architectures) */
#define IPC_64 0x0100 /* New version (support 32-bit UIDs, bigger
message sizes, etc. */

Looks like userspace will "or" the value with IPC_64 to indicate the version it supports.

So the question is, should ausearch report the actual recorded register value, or should it "and" the register with IPC_64 ?

-Steve

Since we're auditing syscalls, I think audit should report what the syscall sees.

-- ljk

OK, that's fine with me. But I wonder where all this should be documented so that we don't get bugzilla's opened by concerned users. Would any particular man page be better than others?

-Steve

Perhaps the auditctl manpage should be clear (if it isn't already) that its auditing the kernel arguments so they may be different than what was passed into a library routine of the same name. Maybe give an example.

This specific one is documented in the Notes section of the semctl(2) and msgctl(2) manpages, which I think is the right place for the details. If someone wants to audit a specific syscall, they should make sure they understand how the syscall works.

-- ljk