[Even though jmjones sent this directly to me, I am replying to the list, with the idea that someone else may have the same concerns about this hook that he does.] On Mon, Oct 01, 2001 at 08:12:10PM -0400, jmjonesat_private wrote: > In other cases, this sort of "information only" call has been questioned > as being 1) expensive and 2) invasive (another hook is, after all, another > hook.) To support its inclusion, could you make a case for the generality > of its usefulness (um, please. :))? Aye, it *is* another (potentially expensive) hook. The case for this hook: I want to know when an executable file has been written to. I don't care who writes to the file, nor do I care about possibly allowing or denying the write. I *do* care about knowing *when* it was written to, and hooking here is important because it removes a race condition. This particular function is one of the few functions with access to the spinlock serializing access to the ETXTBUSY error return when a file is executing and someone tries to open the thing for writing. I think if I tried to place the hook elsewhere, I could be vulnerable to a race condition of someone executing the program before opening it for writing. (I'd be happy to hear ideas on how to tackle this one -- I came to the conclusion that the only way to avoid races is to have a hook here, but I'm open to suggestions. :) I thought about moving the spinlock into the inode structure, so serialized access could be granted in a more fine-grain manner, but .. I don't need a second arsehole ripped for myself. :) Thanks :) _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Mon Oct 01 2001 - 18:50:00 PDT