> > The logical place to make this call would be at d_revalidate time.
> > The new value of the security context is not readily available at
> > that time, as described above. Technically speaking, the file system
> > code could know the new context -- it can do a getxattr, which would
> > return the up-to-date label content. However, this would require
> > knowing the security label xattr name, which is not readily available
> > in RHEL6. (I actually had the code working with correct semantics on
> > RHEL5, which has security_inode_xattr_getsuffix(), but it would be
> > fair to say that it was hacking around the API rather than leveraging
> > it as intended).
> >
> > Hope it makes things clearer.
>
> Yes, thanks. One lingering concern then is that we revalidate
> permissions on read/write via security_file_permission ->
> selinux_file_permission. Within selinux_file_permission, we check
> whether the task SID, inode SID, or policy has changed since the file
> was opened, and if so, we recheck permissions. If you only make the
> call at d_revalidate time, then we'll only update the inode sid on next
> lookup and thus ongoing reads/writes on an already open file will
> continue to succeed even if they should be denied by policy until some
> process on that node attempts another lookup.
Interesting. With plain Unix semantics, a permission check would be done at file open time, and wouldn't be repeated at read/write time. So there's no attempt by the kernel proper to revalidate the associated dentry/inode prior to calling read/write fop. So, if the file owner were to change (for example), the local inode would not necessarily have the correct owner prior to a write, which is probably important. So this is something that transcends the issue of inode security state per se.
Another possible approach here, as noted by GFS folks, is to invalidate inode security state when a lock protecting it is lost. GPFS could certainly take that approach as well (it's done already for "regular" inode state). In this case, it sounds like kernel/LSM code would be responsible to refreshing the inode security state when it's needed (although fs code could also drive this explicitly at d_revalidate time). I'd be fine with that approach.
yuri
