On Thu, Mar 28, 2013 at 09:54:04AM -0400, Steve Dickson wrote:
> From: David Quigley <dpquigl@xxxxxxxxxxxxxxx>
>
> This patch adds the ability to encode and decode file labels on the server for
> the purpose of sending them to the client and also to process label change
> requests from the client.
>
> Signed-off-by: Matthew N. Dodd <Matthew.Dodd@xxxxxxxxxx>
> Signed-off-by: Miguel Rodel Felipe <Rodel_FM@xxxxxxxxxxxxxxxxx>
> Signed-off-by: Phua Eu Gene <PHUA_Eu_Gene@xxxxxxxxxxxxxxxxx>
> Signed-off-by: Khin Mi Mi Aung <Mi_Mi_AUNG@xxxxxxxxxxxxxxxxx>
> ---
> fs/nfsd/nfs4proc.c | 41 +++++++++++++++++++
> fs/nfsd/nfs4xdr.c | 116 ++++++++++++++++++++++++++++++++++++++++++++++++++---
> fs/nfsd/nfsd.h | 6 ++-
> fs/nfsd/vfs.c | 29 ++++++++++++++
> fs/nfsd/vfs.h | 2 +
> fs/nfsd/xdr4.h | 3 ++
> 6 files changed, 191 insertions(+), 6 deletions(-)
>
> diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
> index ae73175..bb17589 100644
> --- a/fs/nfsd/nfs4proc.c
> +++ b/fs/nfsd/nfs4proc.c
> @@ -42,6 +42,36 @@
> #include "current_stateid.h"
> #include "netns.h"
>
> +#ifdef CONFIG_NFSD_V4_SECURITY_LABEL
> +#include <linux/security.h>
> +
> +static inline void
> +nfsd4_security_inode_setsecctx(struct svc_fh *resfh, struct nfs4_label *label, u32 *bmval)
> +{
> + struct inode *inode = resfh->fh_dentry->d_inode;
> + int status;
> +
> + mutex_lock(&inode->i_mutex);
> + status = security_inode_setsecctx(resfh->fh_dentry,
> + label->label, label->len);
> + mutex_unlock(&inode->i_mutex);
> +
> + if (status)
> + /*
> + * We should probably fail the whole open at this point,
> + * but we've already created or opened the file, so it's
> + * too late; So this seems the least of evils:
> + */
> + bmval[2] &= ~FATTR4_WORD2_SECURITY_LABEL;
Is there any way to avoid this?
How does the vfs open code handle this? It has to be able to set a
security contexts atomically on open(O_CREAT), doesn't it?
--b.
--
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
