On Tue, 24 Jul 2001, richard offer wrote: > > > * frm Valdis.Kletnieksat_private "07/24/01 11:08:07 -0400" | sed '1,$s/^/* /' > * > * On Mon, 23 Jul 2001 20:19:15 EDT, jmjonesat_private said: > *> Proposed: passing fd's should be supported wherever possible in the > *> interface and will not constitute the sole reason for a rejection of a > *> patch. Seconded? > * > * I'll conditionally second it. However, could one of the audit people > * verify that fd's are actually available at most/all of the points they > * are concerned about, or are there some show-stoppers in there where they > * need the fd but it isn't actually handy at the moment? > > All the hook locations have ready access to fds with the exception of the > permission() hook in fs/readdir.c and the mmap() hook in mm/mmap.c. The fd > isn't available to the calling function at that time (it was never passed > down from higher up---which we can't change and still maintain kernel ABI > compatability). > > The problem is that these hooks are used elsewhere (permission() all over > the place, mmap() in arch/i368/sys_i386.c) so we can't simply hack the > prototype. An alternative to the LSM_NOFD_AVAILABLE hack^Wflag would be to > have additional hooks (readdir_permission() and mmap_mmap() ?) that don't > have the extra fd parameter. I don't like that as it loses generality and > adding a hook for one location just seems plain wrong to me. > > Passing a known value of the fd (LSM_NOFD_AVAILABLE) at least gives a > module a chance to do something different in those cases. > > * Valdis Kletnieks Thus the "wherever possible" clause in my proposed resolution. Since you've apparently looked in detail at the code... do the places where the fd is "possible" vastly outweigh the places it is not for that hook? Passing a LOT of null information will probably cause problems, in the long run. Passing *some* (a justifiable minority) null information may be arguable. I'd rather not see two versions of the hook, if possible. It conveys the same information to the module as a "dummy" value would. My feeling is if the FD is possible 1 time, and impossible 100 times, then we need to either move the level of the permission() hook, create another hook that addresses the need indirectly, OR, consider going without the FD. If it's possible 90 times and not 10, then pass a "null" value... which actually will have some information value to the service routine. Also, if there's an arguable way to backtrack from what IS passed to a definitive FD, that would be a consideration. Has your analysis resulted in a ratio of "available to unavailable" function invokations, FD-wise, and/or a ratio of how many times they may be invoked in a running system... or any other measure of magnitude of this problem in a running system? ++++++++ This is an example of "before the fact" feedback to somebody doing coding that will give a "clue" to that person what MIGHT be acceptable to the poster, perhaps before that person wastes a huge amount of time and talent making a decision and finishing a patch that would result in flat rejection. While my comments after seeing the patch may differ with regard to how it is applied, I believe this information increases the focus of efforts toward making a "good" LSM interface. The idea of "give us a patch THEN we'll comment on it" wastes effort in directions we don't want to go... and prevents the coder from gaining any pre-patch benefit from discussion. After all, coders are not omniscient (apologies to those who think they are.) I hope others will comment upon possibly acceptable solutions to this problem. ++++++++ > richard. > 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 Jul 24 2001 - 15:13:52 PDT