From mboxrd@z Thu Jan 1 00:00:00 1970 From: "paul moore" Subject: listening to /dev/audit in a pthread program Date: Fri, 20 Apr 2007 15:35:34 -0700 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.redhat.com (mx2.redhat.com [10.255.15.25]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l3KMZe2Q014379 for ; Fri, 20 Apr 2007 18:35:41 -0400 Received: from bay0-omc3-s26.bay0.hotmail.com (bay0-omc3-s26.bay0.hotmail.com [65.54.246.226]) by mx2.redhat.com (8.13.1/8.13.1) with ESMTP id l3KMZdr2006802 for ; Fri, 20 Apr 2007 18:35:39 -0400 Message-ID: <000401c7839c$359b1040$656fa8c0@centrify.com> 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@redhat.com List-Id: linux-audit@redhat.com I have an test app that quite happily does an audit_set_pid and then sits there reading /dev/audit. It works fine if its in the lead thread. But when I run the same code in my real app it runs in a different thread. No matter what PID I pass to the audit subsystem it complains that nobody is listening I did audit_set_pid(....getpid...) - no (passes the pid of the manager thread) I did audit_set_pid(....gettid...) - no (passes the pid of the LWP) (I dont really mean I did gettid - I did syscall(_NR_gettid)) I can see in the complaint message that I have given it the pid I intended to. I can see in gdb that my LWP id is the same as the one I send to the audit subsystem - ie gettid worked. Is this a known issue? Heres the code snippet void listen() { // register for events pid_t mytid = (pid_t)syscall(__NR_gettid); int res = audit_set_pid(m_auditFD, mytid, WAIT_YES); res = audit_set_enabled(m_auditFD, 1); assert(res >= 0); static audit_reply reply; while (true) { res = audit_get_reply(m_auditFD, &reply, GET_REPLY_BLOCKING, 0); if (res < 0) { printf("exit audit %d %d\n", res, errno); break; } printf("got event %.*s\n", reply.msg.nlh.nlmsg_len, reply.msg.data); } } The thread sits waiting on the audit_get_reply call, so the FD is open