Hi,
I'm a developer on the IBM General Parallel File System (GPFS) team. We are currently looking into implementing SELinux inode labeling support. In the process, we've run into some complications that have to do with the semantics of the Linux LSM API. We've discussed the issue briefly with Eric Paris from RedHat, who has recommended that I bring up this topic on a public list, since it concerns a larger issue of LSM interaction with cluster file systems. The idea here is not just to make a change for the benefit of an out-of-tree file system, but rather improve the LSM API to be friendlier to cluster file systems in general.
The issue has to do with the semantics of multi-node xattr updates. The desirable behavior is simple: a change in an inode security label (stored as an xattr) made on nodeA should be visible on all other nodes on the next access. As far as I can tell, the current SELinux code would initialize the inode security state on the first access (e.g. via security_d_instantiate/inode_doinit_with_dentry), and from that point on the cached security state is considered valid, until the inode is destroyed or reused. Any subsequent inode_doinit_with_dentry call would be a no-op, since isec->initialized is true. There's no way to clear 'initialized', as far as I can see. This works when all changes to the inode are local, and a local setxattr call would update the inode security state. However, if the security label has been changed on another node, some mechanism is needed to update the cached security state. One could achieve this by using security_inode_notifysecctx if the value of the security context is known. However, in the general case retrieving the context value would require some knowledge about the implementation details of LSM (like the name of the security label xattr), and such knowledge is currently kept within LSM code, and arguably should remain so. In other words, one would have to resort to hacking.
To remedy this situation, a new API is proposed, courtesy of Eric Paris:
void security_inode_refresh_security(struct dentry *dentry);
The semantics would be similar to what SELinux inode_doinit provides: for the SECURITY_FS_USE_XATTR case, inode security state would be set based on the value of the security label fetched via getxattr -- even if the security state is already initialized. For other labeling behaviors, the call could be a no-op if security is already initialized, and an equivalent of inode_doinit otherwise.
Does this API look useful, in particular to other cluster file systems?
Thanks,
yuri
