> >>> If we made the invalidation point an explicit refresh of the label at
> >>> least the filesystems would be able to control both of those
> >>> problems.....
> >
> > So far the only case that has been discussed is one in which there
> > is one security attribute on the file. While we don't have it yet there
> > are a couple of efforts underway to support multiple concurrent LSMs.
> > It is also plausible for an LSM to use more than one security attribute
> > on a given file. An approach based on a secid interface may not work
> > in either scenario. If you want a comparative example, look at directory
> > default ACLs, which are important security information, but are nor used
> > to make access decisions on the object to which they are attached.
>
> I'm still leaning towards a solution in which the filesystem needs to
> tell the LSM that it's labels are invalid (I suggest that be done on
> any change in the security.* namespace) and that same call needs to
> cause the LSM to refresh its labels. I seem to think that such a call
> would work just fine with any LSM stacker or even
> multi-attribute/multi-label LSM (which uses the security.* namespace).
In the "pull" model that GFS2, OCFS2, and GPFS apparently follow, on a given node the file system code doesn't know that an xattr in a security.* namespace got modified on another node. All that is known is that the lock protecting inode xattrs has been lost, so now everything protected by this lock is invalid. The next time this information is needed, it has to be re-initialized (e.g. by reading data from disk). The security attribute label may or may not have changed, that is not known at that point, but the inode security state has to be re-initialized in case it did. So it sounds like all distributed file systems would benefit from an LSM API call that invalidates inode security state.
I think the tricky part here is how/when to drive inode security state refresh, once it has been invalidated. File system code could do this easily at dentry revalidation time, possibly even using existing API, like security_d_instantiate (provided it does a full re-init, using getxattr, if it sees that the inode state has been invalidated). A dentry is conveniently available at this juncture.
Permission checking prior to a write on an already open file is a somewhat different problem. In the current code, the permission check is made before file system code gets involved, so the call to re-init inode security state has to be made in VFS or LSM code, before the permission check. It would probably be easier/more logical to do this in security_file_permission. Since the latter is passed struct file *file, a dentry could be easily obtained as file->f_path.dentry.
yuri
