Unless I'm missing something, create security_ops->register() create security_ops->unregister() If register_security() detects an existing module registration, instead of failure, pass the new ops pointer to the security_ops->register() function. If the module can't provide "chaining" or replacement functions, it could just fail, if it CAN, it returns success and can worry itself if it calls the new hook before or after or never, and possibly unregister and register a new structure since it holds "the magic address". During the module exit, it can just pass an unregister down the line. Perhaps this is too simplistic, but it has the advantage of allowing multiple security modules to register and chain, if they're so designed, and keeps the "magic structure address" safely hidden by the module chain, and all modules that are "the bottom line" can just be the last loaded and fail any requests to think differently. Only ONE module ACTUALLY has the pointer to security_ops registered in the kernel, and it need never tell. [[ IDEA TOO SIMPLE / REPEAT ]] To use my LSMEXAMPLE.C program as an example LSMEXAMPLE is loaded first, CAPABILTY_PLUG is loaded second... the security_ops structure in the kernel is already not-dummy, so it passes the request to LSMEXAMPLE via security_ops->register, which picks up that structure, and chains to it, returns success. System runs, is safe(ish) because the chain ultimately passes down to CAPABILITY_PLUG, and the lsmstats counters are there for the plucking. The unregister reverses the process. The overhead on a "last link" is simply to return an error, and module registration isn't likely to happen 30 times a second so the overhead is rather trivial (except for that of hooking down the chain, which is a cost/benefit decision when the admin builds the chain.) Adding it to the "spec" now saves modules that want this from coming up with incompatible solutions. What Am I Missing? J. Melvin Jones |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ 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 : Tue May 22 2001 - 12:03:34 PDT