On Sun, Feb 20, 2011 at 3:16 PM, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > On 2/18/2011 2:40 PM, Eric Paris wrote: >>> 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). The biggest problem is if the 3 cluster filesystems in question can handle an interface that requires a dentry and if they can handle the fact that we do permissions checks on read/write and would like those operations to start failing immediately if another node changed the label. I really don't see any other way to solve the problem.... -Eric -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
