Greg, Thank you for the recommendations/suggestions. Some of which I simply didn't know like debugfs and others were well, oversights. I'll make the necessary changes (as well as the ones in other postings) and repost. I would like to clarify the following: > +extern int sandbox_avail; /* can't use MODULE_STATE_GOING notification */ That's a pretty horrible global symbol name. What exactly are you trying to test for here? Initially it wasn't clear whether or not EVM/SLIM should be a single module or two. We eventually decided that lsm modules should provide a single function so that when newer/different/better implementations became available, they could easily be replaced. Originally, both EVM and SLIM were meant to run either independently or in conjunction with each other. However, there were a couple of instances, such as here, where EVM needed some context information in which it was running and where SLIM needed information from EVM. (The other cases will be discussed in response to Stephen Smalley's append.) In this case, EVM needed context information as to whether or not there was a MAC module stacked. EVM, when running with a MAC module, only caches the analysis in the i_security without doing MAC enforcement. By defining .notifier_call, there wasn't a need for a global symbol, which introduced an EVM dependency on SLIM. The problem with the .notifier_call was the lack of a MODULE_STATE_GOING notification when a module is removed. As stacker modules can not be removed, I guess this is a moot point. So I could go back to using .notifier_call and remove the global symbol name. However, a simpler solution would be, using a more meaningful name, make this a runtime variable indicating whether or not to defer MAC. Mimi Zohar
This archive was generated by hypermail 2.1.3 : Thu Nov 17 2005 - 13:29:04 PST