From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: PATH records show fcaps Date: Mon, 20 Oct 2008 06:56:32 -0400 Message-ID: <200810200656.32522.sgrubb@redhat.com> References: <1224343392.3189.74.camel@paris-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1224343392.3189.74.camel@paris-laptop> 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: Eric Paris Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Saturday 18 October 2008 11:23:12 Eric Paris wrote: > type=PATH msg=audit(1224342849.465:43): item=0 name="/bin/ping" inode=49227 > dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:ping_exec_t:s0 cap_permitted=0000000000002000 > cap_inheritable=0000000000000000 The kernel abbreviates these as: capprm & capinh in the proc file system. I'm thinking shorter names would save some disk space. > This good? If either cap_permitted or cap_inheritable have anything set > I show them both. And they are otherwise missing to save disk space? > In the above example would you rather I only showed > cap_permitted and dropped cap_inheritable? No. Its my understanding that apps could have something inheritable by children and we'd want to know exactly what that was. > Did I see correctly that it's possible to set a cap_effective on a file? Yes. > Does it do anything? I didn't see that getting used or read in the kernel, > so I didn't put any way to display it in kernel.... That would be strange to have a field that is not used. I'll leave code review to others. Thanks for working on this patch! -Steve