# Re: \[PATCH v2\] security: Return xattr name from security\_dentry\_init\_security()

- From: Vivek Goyal \<vgoyal@redhat.com\>
- Date: 2021-10-20 12:31:40 
- List: linux-security-module
- Page: https://ratatoskr.run/linux-security-module/2021/10/216575
- Thread: https://ratatoskr.run/linux-security-module/2021/10/215768/t.md

```text
On Wed, Oct 20, 2021 at 08:24:44AM -0400, Paul Moore wrote:
> On Tue, Oct 12, 2021 at 9:23 AM Vivek Goyal [ref] wrote:
> >
> > Right now security_dentry_init_security() only supports single security
> > label and is used by SELinux only. There are two users of of this hook,
> > namely ceph and nfs.
> >
> > NFS does not care about xattr name. Ceph hardcodes the xattr name to
> > security.selinux (XATTR_NAME_SELINUX).
> >
> > I am making changes to fuse/virtiofs to send security label to virtiofsd
> > and I need to send xattr name as well. I also hardcoded the name of
> > xattr to security.selinux.
> >
> > Stephen Smalley suggested that it probably is a good idea to modify
> > security_dentry_init_security() to also return name of xattr so that
> > we can avoid this hardcoding in the callers.
> >
> > This patch adds a new parameter "const char **xattr_name" to
> > security_dentry_init_security() and LSM puts the name of xattr
> > too if caller asked for it (xattr_name != NULL).
> >
> > Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
> > Reviewed-by: Jeff Layton <jlayton@kernel.org>
> > ---
> >
> > Changes since v1:
> > - Updated comment to make it clear caller does not have to free the
> >   xattr_name. (Jeff Layton).
> > - Captured Jeff's Reviewed-by ack.
> >
> > I have tested this patch with virtiofs and compile tested for ceph and nfs.
> >
> > NFS changes are trivial. Looking for an ack from NFS maintainers.
> >
> > ---
> >  fs/ceph/xattr.c               |    3 +--
> >  fs/nfs/nfs4proc.c             |    3 ++-
> >  include/linux/lsm_hook_defs.h |    3 ++-
> >  include/linux/lsm_hooks.h     |    3 +++
> >  include/linux/security.h      |    6 ++++--
> >  security/security.c           |    7 ++++---
> >  security/selinux/hooks.c      |    6 +++++-
> >  7 files changed, 21 insertions(+), 10 deletions(-)
> 
> This looks fine to me and considering the trivial nature of the NFS
> changes I'm okay with merging this without an explicit ACK from the
> NFS folks.  Similarly, I generally dislike merging new functionality
> once we hit -rc6, but this is trivial enough that I think it's okay;
> I'm merging this into selinux/next now, thanks everyone.

Thanks Paul. I agree that this a trivial fix with no functionality
change and probability of this breaking something is very very low.

Vivek

```