Messages in this thread | | | Subject | Re: Problem with accessing namespace_sem from LSM. | From | Tetsuo Handa <> | Date | Thu, 8 Nov 2007 07:04:23 +0900 |
| |
Hello.
Christoph Hellwig wrote: > > Isn't security_inode_create() a part of VFS internals? > It's not. security_inode_create is part of the LSM infrastructure, and > the actual methods are part of security modules and definitively not > VFS internals. The reason why I want to access namespace_sem inside security_inode_create() is that it doesn't receive "struct vfsmount" parameter. If "struct vfsmount" *were* passed to security_inode_create(), I have no need to access namespace_sem.
And now, since calling down_read(&namespace_sem) causes deadlock, I'm looking for a solution. What you said ("I'd start looking for design bugs in whatever code you have using it first.") sounds "never try to implement pathname based access control at security_inode_create()", which makes AppArmor (for OpenSuSE 10.1/10.2) and TOMOYO unable to apply access control.
At first, I thought that this lockdep's warning is a false positive, since "struct inode" is allocated/freed dynamically. But the warning still appears even after I disabled freeing memory at destroy_inode() in fs/namei.c (so that address of locking object in "struct inode" never be reused), it is likely genuine.
Regards.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |