On Tue, Aug 07, 2001 at 07:47:45AM -0700, richard offer wrote: > > You're right this policy does not in itself use fds. But the argument was > that fds are not useful for any policy. > > The policy could have been implemented by using the fd parameters to the > file_ops hooks and revoking access on read/write, but that would have meant > adding new hooks (open/post_open/close) and misleading since this was the > obvious way of implementing the policy (that's how Solar impemented it). I > was honest. > > I can't win. Actually I think you just proved my argument to the 'fd' issue in that they are not needed to be passed in those functions for everyone (with the exception of audit) to do what they want to do. By implementing the only existing security policy that anyone could think might need that information, you proved that this was not so. Thanks! :) > What about living in the security directory (where the config file is now). > Each in its own separate subdir ? That sounds good. I'll move the files around later, after Stephan gets his latest changes into the tree. > Perhaps they should be named <policy>_lsm.o to denote them as lsm modules > rather than any other type ? On an installed system, that would lead them > to be installed under /lib/modules/*/kernel/security/policy_lsm.o ? '*_lsm' is not really needed. It's up to the individual developer what to name their module. All you have to do is not collide with any of the existing module names and you will be fine :) thanks, greg k-h _______________________________________________ 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 Aug 07 2001 - 08:41:29 PDT