Since we've now decided on a mechanism to identify modules within their own family, should we change the "name" for security_ops->register to an unsigned, for consistancy? This distinction/argument was added to allow the stacking/multiplexing module to identify the module requesting subordinate registration and to provide a very useful means for non-family or primary-stacking modules to make sure they're in the right place (i think). At this point... the magic number seems to be the way to go. Of course, if the "non-recommended but simply mentioned convention" of MD5 hashing is adopted, the number can be derived (I agree with richard offer theoretically... keys are not random and any one-way key can only have (number_of_permutations/total_space) uniqueness. Otherwise, leave it to userspace (?). The modid can be picked up from the structure passed, too, I think. If we eliminate this argument altogether, does that keep the "no support for willy-nilly module stacking" people happy? I'd rather provide no support but no encumberance than no-support/possible encumbrance, via a single call that would pass the registration to the module IF there was a pre-registered one, but I don't think that gives the assurance necessary for the LARGE/MONOLITHIC module solutions... unless they have four-byte responses (FAIL FAIL FAIL) or don't use the modid at all. Ummmmmmm, hey, is this too much to ask to reduce complexity in the interface? If everybody has check-code already, this would help stackable: --- Let the register function (not mod_register) handle it... just add a hook that passes the registration UP to the module IF and ONLY IF a module has been previously registered? Pro+Con issue: stacking modules CAN multiplex/resolve multiple modules if they want. They'll fail in the world if they haven't addressed ALL of the issues. Awareness of primacy is a policy issue... let's not prefer one policy over another. --- Is this a make-or-break issue to anybody? 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 : Fri Aug 24 2001 - 11:46:45 PDT