From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linda Knippers Subject: Re: [PATCH] IPC_SET_PERM cleanup Date: Tue, 09 May 2006 13:47:26 -0400 Message-ID: <4460D5AE.8040700@hp.com> References: <445BB351.2040303@hp.com> <200605091121.21457.sgrubb@redhat.com> <4460B6A2.7060801@hp.com> <200605091155.34730.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200605091155.34730.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 >>If someone is looking for the records for a particular uid, wouldn't >>> they expect to get the records generated by someone with that uid? > > Not necessarily. I would like to present all matches of uid and let them > decide what is relavent. It seems to me like you could be generating alot of noise. What will an ausearch -ui give you? The manpage says: > -ui > Search for an event with the given user ID. I wouldn't expect that to include events generated by other users that used the user id as an argument. >>At this point there are already a bunch of uid fields (auid, uid, euid, >>> suid, fsuid, iuid, ouid) in various audit records, and a similar set >>> of guid files, so would you be happier with nuid, ngid, etc? > > > Does ouid and ogid not fit? I'd like us to define what we need in the parser > API and then use it in the audit messages. Ancilliary words like new, old, > last, first should not be tied with an underscore. If you find any, let me > know. According to your spec, ouid means file owner uid, so that doesn't seem to fit. I'm starting to wonder whether we actually need the IPC_NEW_PERMS record. We don't spell out similar information for chown, for example. In that case, the new owner is a1 field. Do we treat IPC's differently because their argument is a structure pointer? In any case, if someone truly wanted to get all audit records that had the uid either as part of the subject/object identity and also included all records that had the uid as an argument, they'd need to look at the a* fields for other system calls as well. Since we don't look at the a* arguments for other syscalls, it doesn't seem like we should include the arguments for the IPC syscalls if someone is searching for the records generated by a uid. -- ljk