From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: offsets for 64bit IPC mechanisms Date: Wed, 10 Jan 2007 11:02:04 -0500 Message-ID: <200701101102.04270.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from discovery.boston.redhat.com (discovery.boston.redhat.com [172.16.80.171]) by mail.boston.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l0AG30jl007246 for ; Wed, 10 Jan 2007 11:03:00 -0500 Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Linux Audit List-Id: linux-audit@redhat.com 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