From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [RFC PATCH ghak9 0/3] audit: Record the path of FDs passed to *at(2) syscalls Date: Wed, 25 Jul 2018 08:48:22 -0400 Message-ID: <5402595.goYXf9ZsuL@x2> References: <20180712113633.10687-1-omosnace@redhat.com> <1590186.5EpvlznUaH@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Ondrej Mosnacek Cc: Richard Guy Briggs , Linux-Audit Mailing List List-Id: linux-audit@redhat.com On Wednesday, July 25, 2018 3:44:07 AM EDT Ondrej Mosnacek wrote: > On Wed, Jul 25, 2018 at 3:11 AM Steve Grubb wrote: > > On Tuesday, July 24, 2018 6:15:54 PM EDT Paul Moore wrote: > > > On Tue, Jul 24, 2018 at 10:12 AM Ondrej Mosnacek > > > > > > > Beyond that, there is really no information in the records that would > > > > allow reconstructing which PARENT path belongs to which CREATE/DELETE > > > > path... (Intuitively you can guess that src will come before dst, but > > > > that is not very reliable.) I think a "parent inode" field in the > > > > PATH > > > > records could fix this, but maybe there is a better solution... > > > > > > I have my suspicions, but I would be curious to hear from Steve how > > > the reconstruction is typically handled. > > > > For any *at function when the dirfd is not AT_FDCWD, it goes badly. If > > its a old style syscall without the dirfd, then if the first character > > is '/' use that. Otherwise concatonate cwd and path and pass it to > > realpath to sort out. > > In that case it seems the best fix for openat() et al. would be to > somehow always force outputting the full path when dirfd != AT_FDCWD. > Hopefully that won't require too much hacking around... What is asked for is the full path that dirfd was opened with. I can take care of everything else. -Steve