I'm not sure what the proposed hook would be for except to identify it
as concerned with nfs. Perhaps the hook could return the names of
attributes that it wants nfs to provide.
I'm not quite sure what you're proposing? I'm sure someone would find
another use for this hook though. The inode_getsecctx hook we made for
Labeled NFS was already merged because it was needed for providing
"persistent" label support for sysfs (meaning that it persisted inode
eviction from memory). The problem is that we have no real way to ask in
the NFS code if this is an LSM that can be used with Labeled NFS. In the
xattr code we have the new ismaclabel hook we add which allows us to
verify the xattr used as belonging to a label based LSM however we need
an xattr from userspace for that. The reason this is required is that
the server will need to fill out its capability mask to indicate it
supports security labeling. In addition the client also needs to know if
its running a security label based LSM because it will need to mask out
the label fattr bit from its getattr calls if it doesn't support it. We
can override this in SELinux by giving it a context mount but if we
don't then it will need to know whether or not to be pulling security
labels back.
I think the point I'm trying to make is that we need to define the
interface which if you implement it you are supported. For label
import/export we have inode_{get,set,notify}secctx. For checking for
xattr suitibility we have the new ismaclabel lsm call. Now the final
thing we need to do is a call to determine if the lsm is suitable for
Labeled NFS export meaning that it agrees to the semantics. Is
inode{get,set,notify}_secctx and ismaclabel sufficient? I'm tempted to
say we can make a call to inode_getsecctx and if it failes with
EOPNOTSUPP we say we don't support it but then we need an initial file
to call that on. This is why I'd rather have a LSM call that we can make
that gives us a yes/no answer.
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
