Re: resolving full path when creating a new file onfreebsd 4.x (and more)

Patrick Bihan-Faou wrote:
> Well would'nt generating the ON_OPEN event after the open has completed have
> a nasty side effect ? Namely the file would already be created even if the
> dazuko daemon decided that the open should be blocked.

Yes, this is correct. But for monitoring applications it was acceptable. 
With your new logic this will no longer be an issue. I will be porting 
this logic to the other platforms as well.


> Yes I have seen this announcement. Is FIST portable to FreeBSD as well ? If
> yes that's probably the best solution.

FiST supports Linux, FreeBSD, and Solaris.


> In the meantime I'll handle the missing syscalls.

Great!


> Well for one I'd like to see more type of event monitored (this is specific
> to an application I am considering):
> 
> - renames (needs a change in the event structure to support 2 filenames as
> noted in a previous thread)
> 
> - symlink/hardlink creations/modifications (I did not look at what would be
> needed to implement that for now, but like for rename having to filenames in
> the event structure seems to be a must)

Both of these items should be simple with the new logic you have provided.


> - more precise information on the written parts of the files (i.e.
> offset+len)

I would need a specific example to fully understand what exactly you want.

I have added your code to the main CVS branch. I made some minor 
modifications. It seems that NDFREE() does not need to be called if 
namei() fails.

I also want to keep the lookups to NOFOLLOW for now. Probably the best 
solution would be to do a NOFOLLOW and if it is not within the included 
paths, try a FOLLOW. This would produce the best results and eliminate a 
long lasting known problem.

I will be testing your new FreeBSD code heavily over the next few days. 
If it runs well, I will copy it to the FreeBSD5 version and port it to 
the Linux version. (I will need to investigate how to handle this with 
RSBAC, since RSBAC uses its own functions and probably does not return 
information for non-existant files.)

John Ogness

-- 
Dazuko Maintainer