>> 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.
>
[Resending because I sent it from the wrong identity.]
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
