On Thu, Jul 26, 2018 at 4:12 AM Ondrej Mosnacek <[email protected]> wrote: > On Wed, Jul 25, 2018 at 3:11 PM Steve Grubb <[email protected]> wrote: > > On Wednesday, July 25, 2018 9:02:50 AM EDT Ondrej Mosnacek wrote: > > > On Wed, Jul 25, 2018 at 2:48 PM Steve Grubb <[email protected]> wrote: > > > > On Wednesday, July 25, 2018 3:44:07 AM EDT Ondrej Mosnacek wrote: > > > > > On Wed, Jul 25, 2018 at 3:11 AM Steve Grubb <[email protected]> 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 > > > > > > > <[email protected]> > > > > > > > > > > > > > > > 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. > > > > > > But where/how should that path be logged? In case of renameat(), for > > > example, we have 6 (!) path components: > > > <src_dir>/<src_parent>/<src_child> and <dst_dir>/<dst_parent>/<dst_child> > > > > > > (I am assuming the child paths always represent just the last path > > > component based on the observed inodes of the parent/child records.) > > > > > > Current record format can distinguish between PARENT and child > > > (DELETE/CREATE), but there is no nametype for the dirfd path. That's > > > why I am leaning towards just logging the full "<*_dir>/<*_parent>" > > > path in the PARENT record. Or do you prefer that we add a new nametype > > > for the dirfd path? > > > > You could make a new nametype so that we can make sense of it. But do you > > have all of the required information for a PATH record? I thought that you > > were making a new record type since you have abbreviated information. > > I think it should be possible to collect that information by putting > hooks in the right places of the filesystem code (and fixing the > current ones). > > To be honest, the reason why I had jumped right to making a new record > type was Paul's wording in the issue description ("We may need a new > auxiliary record type since this is neither the cwd or path." ...
For future reference, when I say "may" I do really mean it; it *may* be a good idea, but it *may* also be a garbage idea ;) -- paul moore www.paul-moore.com -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
