On Thu, 2005-11-17 at 17:29 -0500, David Safford wrote: > We did not understand that d_instantiate is the preferred approach, > partially because it is not well documented in security.h. If this > is the better method, it would certainly seem possible to move to this > hook. Reading security.h is a poor substitute for looking at a real working implementation of a LSM that is already upstream. I'd certainly encourage adding inline documentation to security.h for the d_instantiate hook (and others that are presently undocumented), but in the end, the best source of information about how to write a LSM is going to be examining the code of an existing upstream LSM, not the comments in that header. The security_d_instantiate hook was introduced precisely for the purpose of inode security initialization, as discussed in the linux-security-module and linux-kernel mailing list archives. Naturally, you want to use security_inode_init_security to set up newly created inodes (and if it lacks something, you want to adapt it, not re-introduce post_create hooks). > After conversion of the configuration code to securityfs, > we allow only one initial configuration (which we do in > the initrd, when there is only the one init process), and > then we remove the securityfs config file. That seems fairly limiting - why not just provide locking? -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Fri Nov 18 2005 - 04:51:05 PST