Jesse Pollard wrote: >A file may have its permissions changed to deny the process access. >[...] may want to deny access to a file after forking [...] Well, if you want a policy that has these semantics, then you can't take advantage of not trapping on read()/write(), that's true. Fair enough. On the other hand, this policy is "Not The Unix Way", as someone alluded to earlier. In Unix, file descriptors are capabilities. And yes, performance will hurt under such a policy, but I'd argue that this is just the unavoidable cost of trying to implement policies that are radically at odds with the fundamentals that Unix is built on. I guess the important thing is to continue to make radically- different policies possible, even if it is hard to make them perform well without major changes to the Linux kernel. In the end, I guess modules that want good performance can pick a policy with Unix-like semantics where there is no need to mediate read()/write(), and modules that want radically-different policies will need to mediate read()/write() and pay the performance cost. I don't see any way to avoid this tradeoff, and as long as both options are open to both parties, it seems like everyone can go home happy. Am I right? _______________________________________________ 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 Apr 13 2001 - 16:03:43 PDT