* Charles Levert (chuckat_private) wrote: > 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. They get the same 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. Yes, you're right. It's easily available from the call site, however. > Is permission called from open(), or is it called only from read() > or write()? I would rather have open() return an error. open() thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net _______________________________________________ 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:35:30 PDT