Re: [nfsv4] New Version Notification for draft-cel-nfsv4-linux-seclabel-xtensions-00.txt

[Chuck Lever <[e-mail]>]

> On May 3, 2018, at 11:03 AM, J. Bruce Fields <[e-mail]> wrote:
> 
> On Wed, May 02, 2018 at 06:50:31PM -0400, Chuck Lever wrote:
>>> On May 2, 2018, at 6:36 PM, Quigley, David <[e-mail]>
>>> wrote: Also having them as 3 different LFS ids make no sense. The
>>> LFS is supposed to describe the format of what you are sending and
>>> receiving for the sec_label field. Unless something changed in the
>>> last rounds of revisions to the sec_label support there should only
>>> be one value per file?
>> 
>> A file can have capabilities associated with it, a security.ima xattr,
>> and a security.evm xattr. All three are separate objects and can
>> change independently of each other. Capabilities and IMA are not at
>> all related to each other, so at least these two need separate LSF
>> numbers.
> 
> The client doesn't have a way to query them separately.  All you can do
> is send a GETATTR {FATTR4_SEC_LABEL}, and then the server can only
> return one thing.  So, I agree, overloading the security labels in this
> way doesn't work.  I overlooked that!
> 
> It's no problem to define a couple new attributes instead, let's just do
> that.  That will also give clients an easy way to query for IMA or
> file capability support by querying the supported_attrs attributes.

That's what I was thinking too. Dave's extensibility work should make it
straightforward to add these new attributes.

In terms of I-Ds, perhaps I should specify the new IMA and file capabilities
attributes in separate documents. Is it still reasonable to submit the first
revision of these as WG documents rather than personal drafts?


--
Chuck Lever