dazuko-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dazuko-devel] resolving full path when creating a new file onfreebs


From: John Ogness
Subject: Re: [Dazuko-devel] resolving full path when creating a new file onfreebsd 4.x (and more)
Date: Wed, 01 Sep 2004 22:11:14 +0200
User-agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.1) Gecko/20040808

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]