On Wednesday, July 25, 2018 3:44:07 AM EDT Ondrej Mosnacek wrote:
On Wed, Jul 25, 2018 at 3:11 AM Steve Grubb <sgrubb(a)redhat.com>
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 <omosnace(a)redhat.com>
> >
> > > 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