[PATCH v2] security: Return xattr name from security_dentry_init_security()

[Vivek Goyal]

On Wed, Oct 20, 2021 at 08:24:44AM -0400, Paul Moore wrote:
> On Tue, Oct 12, 2021 at 9:23 AM Vivek Goyal <vgoyal at redhat.com> 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 at redhat.com>
> > Reviewed-by: Jeff Layton <jlayton at 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