On Mon, 2015-08-24 at 13:42 -0400, Stephen Smalley wrote: > On 08/20/2015 02:19 PM, Andreas Gruenbacher wrote: > > For that case, the file system has no way of updating the security > > label before > > selinux next uses it. Things also don't fix themselves over time; > > when selinux > > rejects access, the file system never notices. > > The current NFSv4 model is to call security_inode_notifysecctx() to > notify the security module of the new label. Does that not work for > gfs2 or others? It is up to the filesystem client side code to > actually > detect the change and fetch the new value, then push it to the > security > module via the security_inode_notifysecctx() hook. I'm told that most of these filesystems have NO push to clients about changes. Only clients 'pull'. Image the inode has the label "no_access". I try to access it on node1. We pull the inode into core and set the isec to no_access and then get denied. Now on node2 I relabel to "yes_access". There is no push mechanism for node1 to find out. Now on node1 if I call access() I "should" have access, but the VFS/LSM will never call the filesystem code, so fs never knows to call security_inode_notifysecctx(). Somehow we have to get into the FS function so the FS can tell us that it is invalid... -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
