[Cluster-devel] [RFC 00/11] Inode security label invalidation
Eric Paris
eparis at redhat.com
Mon Aug 24 20:47:58 UTC 2015
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...
More information about the Cluster-devel
mailing list