From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Paris Subject: Re: [PATCH] Audit: close race between audit_syscall_exit and proc_loginuid_read Date: Wed, 03 Oct 2007 14:43:19 -0400 Message-ID: <1191436999.9506.55.camel@localhost.localdomain> References: <1191435695.9506.50.camel@localhost.localdomain> <200710031429.35643.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200710031429.35643.sgrubb@redhat.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: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Wed, 2007-10-03 at 14:29 -0400, Steve Grubb wrote: > On Wednesday 03 October 2007 14:21:35 Eric Paris wrote: > > audit_syscall_exit() calls audit_get_context() which returns the > > tsk->audit_context but then also sets tsk->audit_context=NULL. > > The preferred way to solve this problem is to promote loginuid to be part of > the task structure. We also have another problem where if the audit system is > temporarily disabled, loginuid will not be set in any new programs. What we'd > like to have happen is loginuid be available and usable all the time so that > we always know the auid when the audit system starts back up. While obviously possible I don't see a reason that this patch is bad, wrong, or shouldn't go in. If things other than audit want to make use of the loginuid I wouldn't see a problem putting it in the task struct but as it stands now this patch fixes an obvious race for a solely audit problem. -Eric