On Thu, Jun 30, 2016 at 11:44 AM, Daniel Jurgens <danielj@xxxxxxxxxxxx> wrote: > On 6/30/2016 10:10 AM, Yuval Shaia wrote: >> On Thu, Jun 23, 2016 at 10:52:49PM +0300, Dan Jurgens wrote: >> >>> +static void (*ib_flush_callback)(void); >> Do we really want to have such ib_ prefix in security/ directory? >> >>> + if (ib_flush_callback) >>> + ib_flush_callback(); >> How about some generic mechanism (such as a list) in case more >> modules/drivers would like to register callbacks? >> ( assuming this is no longer RFC :) ) >> > Paul Moore and I were having a higher level discussion about this in the 00/12 thread. I think your suggestion makes sense, perhaps Paul will weigh in when he reaches this patch. I'm still working on understanding IB, but my current thinking is very similar to Yuval's suggestions. There is a risk of creating a general purpose mechanism to solve a specific, isolated problem, but adding a LSM notification mechanism does seem like a reasonable thing to do. My current thinking is to have the LSM framework itself, e.g. security/security.c, maintain a list of callbacks (BTW, please make it a RCU protected list) with other non-LSM subsystems registering callbacks, and specific LSMs making notification calls into the LSM framework itself which would handle iterating through the registered callbacks. Since we're going down the general purpose solution route, I might add an event field and a void pointer to the callback, for example: void lsm_notifier_callback(unsigned int event, void *ptr); ... I would expect at first we would only have a POLICY_CHANGE event (ptr set to NULL), but we may want/need to add other events in the future. Make sense? -- paul moore security @ redhat _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
