From: Crispin Cowan <crispinat_private> Date: Fri, 18 Oct 2002 01:31:35 -0700 Could you elaborate on why this is a sign of trouble, design wise? Bacause if you can't even specify the data types, something is severely wrong. It's entirely a black box. That doesn't give it system call status. Compare: read(fd, buf, size) This reads, from file descriptor FD, into BUF of size SIZE. with: security(id, call, args) ??? How would you describe this in a manpage, for example? >There is simply no way we can enfore proper portable typing by >all these security module authors such that we can do any kind >of proper 32-bit/64-bit syscall translation on the ports that >need to do this. THAT I would love to hear about. If all we have to do to save sys_security is change its signature, that'd be great. Well for one thing a pointer to opaque stuff can't be translated properly. You MUST KNOW THE DATA TYPES that are being passed into the system call to translate it properly. Your system call, BY DESIGN, makes the data types opaque and indeterminable. You can only fix this by contradicting yourself. :-) Yes, that will be wonderful. And the LSM team will be pleased to re-work the desing when stackable file systems appear and we can take advantage of them. So we should just stick your crap in now right? No, that is not how things work. _______________________________________________ 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 Oct 18 2002 - 01:38:33 PDT