* 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 richard. ----------------------------------------------------------------------- Richard Offer Technical Lead, Trust Technology, SGI "Specialization is for insects" _______________________________________________________________________ _______________________________________________ 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 - 09:26:35 PDT