[PATCH] cleanups + fixes against audit.56

[Steve Grubb]

On Wednesday 15 June 2005 16:36, Timothy R. Chavez wrote:
> Well, its intuitive that the information being reported is the parent's
> information and not the childs in these certain cases. 

That doesn't matter. If the intent was to report on the file, and the 
directory's mode is reported its wrong.

> But you have to understand how the system call works and I think that's
> where the real problem lies.

This is irrelevant. I tried this on execve. I wanted to know the file's 
execute permissions. What I got was the parent dir's permissions. You don't 
need to know how the syscall works to say that the information being reported 
is wrong.

> To do what you suggest would/could get quite ugly I think.

I think people will want the right permissions for executables. 

>  We can already get all this info from watching the child...
>
> Rik's hook can only give back the _relevant_ information the system call
> was able to use when deciding its courses of action.  In some cases that's
> the parent and in others it's the child.

Let's go back to the CAPP requirements and see what is necessary. If we are 
supposed to have the permissions of the file and not the parent directory - 
that's what we need. If Rik's hook is wrong - so be it, let's do it right.

We are going to trap the changes to file attributes in the file system 
auditing to meet FMY_MSA.1. This means it will generate PATH records. If it 
records by accident, the parent directory - we haven't met the requirement.

This also means the PATH record for -p x will always be wrong. This is used to 
monitor auditd startup attempts and unsuccessful attempts to retrieve audit 
information.

-Steve