From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: Re: [PATCH 06/15] NFSv4: Introduce new label structure Date: Tue, 12 Feb 2013 18:06:23 -0500 Message-ID: <20130212230623.GO10267@fieldses.org> References: <1360327163-20360-1-git-send-email-SteveD@redhat.com> <1360327163-20360-7-git-send-email-SteveD@redhat.com> <20130212220741.GJ10267@fieldses.org> <4FA345DA4F4AE44899BD2B03EEEC2FA91F3CE55C@sacexcmbx05-prd.hq.netapp.com> <20130212223226.GL10267@fieldses.org> <4FA345DA4F4AE44899BD2B03EEEC2FA91F3CE58F@sacexcmbx05-prd.hq.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Steve Dickson , "J. Bruce Fields" , "David P. Quigley" , Linux NFS list , Linux FS devel list , Linux Security List , SELinux List To: "Myklebust, Trond" Return-path: Content-Disposition: inline In-Reply-To: <4FA345DA4F4AE44899BD2B03EEEC2FA91F3CE58F@sacexcmbx05-prd.hq.netapp.com> Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, Feb 12, 2013 at 10:40:46PM +0000, Myklebust, Trond wrote: > On Tue, 2013-02-12 at 17:32 -0500, J. Bruce Fields wrote: > > On Tue, Feb 12, 2013 at 10:28:16PM +0000, Myklebust, Trond wrote: > > > On Tue, 2013-02-12 at 17:07 -0500, J. Bruce Fields wrote: > > > > On Fri, Feb 08, 2013 at 07:39:14AM -0500, Steve Dickson wrote: > > > > > From: David Quigley > > > > > > > > > > In order to mimic the way that NFSv4 ACLs are implemented we have created a > > > > > structure to be used to pass label data up and down the call chain. This patch > > > > > adds the new structure and new members to the required NFSv4 call structures. > > > > > > > > > > Signed-off-by: Matthew N. Dodd > > > > > Signed-off-by: Miguel Rodel Felipe > > > > > Signed-off-by: Phua Eu Gene > > > > > Signed-off-by: Khin Mi Mi Aung > > > > > --- > > > > > fs/nfs/inode.c | 33 +++++++++++++++++++++++++++++++++ > > > > > include/linux/nfs4.h | 7 +++++++ > > > > > include/linux/nfs_fs.h | 17 +++++++++++++++++ > > > > > include/linux/nfs_xdr.h | 21 +++++++++++++++++++++ > > > > > include/uapi/linux/nfs4.h | 2 +- > > > > > 5 files changed, 79 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c > > > > > index ebeb94c..8d5f01b 100644 > > > > > --- a/fs/nfs/inode.c > > > > > +++ b/fs/nfs/inode.c > > > > > @@ -255,6 +255,39 @@ nfs_init_locked(struct inode *inode, void *opaque) > > > > > return 0; > > > > > } > > > > > > > > > > +#ifdef CONFIG_NFS_V4_SECURITY_LABEL > > > > > +struct nfs4_label *nfs4_label_alloc(struct nfs_server *server, gfp_t flags) > > > > > +{ > > > > > + struct nfs4_label *label = NULL; > > > > > + > > > > > + if (!(server->caps & NFS_CAP_SECURITY_LABEL)) > > > > > + return label; > > > > > + > > > > > + label = kzalloc(NFS4_MAXLABELLEN, flags); > > > > > + if (label == NULL) > > > > > + return ERR_PTR(-ENOMEM); > > > > > + > > > > > + label->label = (char *)(label + 1); > > > > > + label->len = NFS4_MAXLABELLEN; > > > > > > > > If you're expecting to be able to store up to NFS4_MAXLABELLEN of data > > > > after the end of the struct, then you want: > > > > > > > > label = kzalloc(sizeof(struct nfs4_label) + NFS4_MAXLABELLEN, flags); > > > > > > Sigh... No. > > > > > > I keep telling Steve that the 'label' needs to be defined as an array, > > > > Yeah, I know, he said in 0/15 that he couldn't do that, so I've been > > reading through these on the assumption I'll find out why not at some > > point.... (Still not seeing it, though.) > > It only makes sense to define label->label as a pointer if you need to > change the pointer value at some time. However, if that is the case, > then why allocate the struct nfs4_label and label string as a single > memory block? It would make more sense to allocate them separately so > that you can free the old label storage after you change the pointer. nfs4_get_security_label() in a later patch is indeed using some passed-in storage instead, but I'm not sure it's doing it correctly. It would seem simpler to pick either inline or separate storage and stick with it throughout. I'd be inclined to favor inline even if it means larger allocations than necessary or an extra copy. Just because it seems harder to mess up. --b.