linux-kernel - Re: [PATCH 07/10] NFSv4: Introduce new label structure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 07 Jul 2010 13:42:15 -0400
From:	Chuck Lever <chuck.lever@...cle.com>
To:	Casey Schaufler <casey@...aufler-ca.com>
CC:	"David P. Quigley" <dpquigl@...ho.nsa.gov>, hch@...radead.org,
	viro@...iv.linux.org.uk, sds@...ho.nsa.gov,
	matthew.dodd@...rta.com, trond.myklebust@....uio.no,
	bfields@...ldses.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org, selinux@...ho.nsa.gov,
	linux-nfs@...r.kernel.org
Subject: Re: [PATCH 07/10] NFSv4: Introduce new label structure

On 07/ 7/10 12:21 PM, Casey Schaufler wrote:
> Chuck Lever wrote:
>> My comments below apply to the other NFS client patches as well.  This
>> seemed like the right one to use for code examples.
>>
>> On 07/ 7/10 10:31 AM, David P. Quigley wrote:

   [ ... snipped ... ]

>>> diff --git a/include/linux/nfs4.h b/include/linux/nfs4.h
>>> index a2abd1a..c512a0c 100644
>>> --- a/include/linux/nfs4.h
>>> +++ b/include/linux/nfs4.h
>>> @@ -167,6 +167,13 @@ struct nfs4_acl {
>>>        struct nfs4_ace    aces[0];
>>>    };
>>>
>>> +struct nfs4_label {
>>> +    void        *label;
>>> +    u32        len;
>>> +    uint32_t    lfs;
>>> +};
>>
>> If we have support for NFS labels in NFSv3, would we also use struct
>> nfs4_label?
>>
>> It seems to me you want something more generic, just like nfs_fh or
>> nfs_fattr, to represent these.  Over time, I'm guessing label support
>> won't be tied to a specific NFS version.  And, you are passing these
>> around in the generic NFS functions (for post-op updates and inode
>> revalidation, and what not).
>>
>> Can I recommend "struct nfs_seclabel" instead?  Then have
>> nfs_seclabel_alloc() and nfs_seclabel_free().
>
> Security has been the primary consumer of labels to date, but
> the xattr concept has always been envisioned as useful in many
> ways. That, and people have so many different views on what is
> and isn't security and whether it is good or evil that you are
> asking to limit the value if you tie "security" to the names.
> Plus, it adds unnecessary characters.

My main point is that the "nfs4" prefix is probably not optimal in the 
long run.  It seems to me that these labels are of generic use in the 
NFS client, and not necessarily specific to version 4.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/