On Wed, Sep 03, 2003 at 02:23:45PM -0700, Chris Wright wrote: > This sounds like multiple mountpoints and bind mounts (both of which can > be specific to the processes namespace) will be problematic for you. Yes. This is what Stephen said too. I have a Linux kernel question then. Assume that a filesystem is mounted both over /a and /b. Then /a/x and /b/x are the same file. In the dcache, do they both get the same dentry, or does each one get its own dentry? If it's the former, then I have a problem. If it's the latter, then I'm fine if I start to walk the tree for a specific dentry. > > > On a similar note, since Trond's intents patch the permission hook now > > > has nameidata available. I'd like to update the API to use nameidata > > > where apropos. Would this help? > > > > Is that file_permission or inode_permission? What would be its prototype? > > int inode_permission(struct nameidata *nd, int mask); I think that would be great. How will you be able to pull this off? security_inode_permission appears both in permission and exec_permission_lite. The nameidata is not available in exec_permission_lite. Is permission called from open(), or is it called only from read() or write()? I would rather have open() return an error. Charles _______________________________________________ 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 : Wed Sep 03 2003 - 15:15:06 PDT