Date: Tue, 08 Apr 2003 17:14:58 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Pawel Jakub Dawidek <nick@garage.freebsd.pl> Cc: Steffen Mazanek <Steffen.Mazanek@unibw-muenchen.de> Subject: Re: Idea related to UNIX directories Message-ID: <3E936602.24CC4EE2@mindspring.com> References: <86vfxpmov5.fsf@pseiko.studfb.unibw-muenchen.de> <20030408192718.GP1280@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Pawel Jakub Dawidek wrote: > > On Tue, Apr 08, 2003 at 09:26:22AM +0200, Steffen Mazanek wrote: > +> I think it would be quit useful to allow some > +> code to be related to e.g. the i-nodes of directories. > +> Consider therefore an example. At first, all > +> directories have a default assignment to save > +> memory. This default assignment may realize > +> permission related stuff. Now some privileged users > +> have the permission to add their own code, which > +> must implement an interface and some standard > +> functions and in addition they are able to trigger > +> some events, e.g. write something to a log-file > +> whenever a user enters the directory or start > +> an application. > +> > +> What do you think about this idea? Is it feasible > +> at all? > > You can try CerbNG, it provides much more than you want. > > http://cerber.sourceforge.net > > There is policy that privide logging of execve() calls with arguments > and all interesting process informations: > > http://cerber.sourceforge.net/policies/log-exec.cb > > You can write policy that will log interesting events with some prefix > and write program that will catch those logs and handle with catched > event. > > If you give me some examples I could help you to write suitable policies. His description indicated that he wants the moral equivalent of database triggers, on lin a filesystem, instead of as a result of having installed database software that supports triggers (e.g. Postgres, from ports). He says he wants to associate some code with the operation, not just be notified of the operation. This would be really easy to abuse, and it might even be possible to abuse to toe-nail in some nasty code. You would also need to substantially revamp per-file attribute storage for the stored scripting code associated with the trigger; in an SQL server, the stored code is stored in a metadata record associated with the object itself. Same for stored code for the LDAP record triggers in the iPlanet and Microsoft Active Directory. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E936602.24CC4EE2>