linux-kernel - Re: [PATCH 08/12] driver-core: Introduce DEVICE_ATTR_ADMIN

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]

Message-ID: <CAPcyv4jeFTWVYEx74AOhHjbgCJpYwcR7waTDx90artGKBvaKrw@mail.gmail.com>
Date:   Thu, 25 Jun 2020 22:09:00 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-nvdimm <linux-nvdimm@...ts.01.org>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Vishal L Verma <vishal.l.verma@...el.com>,
        Linux ACPI <linux-acpi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 08/12] driver-core: Introduce DEVICE_ATTR_ADMIN_{RO,RW}

On Thu, Jun 25, 2020 at 10:06 PM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
>
> On Thu, Jun 25, 2020 at 04:51:03PM -0700, Dan Williams wrote:
> > A common pattern for using plain DEVICE_ATTR() instead of
> > DEVICE_ATTR_RO() and DEVICE_ATTR_RW() is for attributes that want to
> > limit read to only root.  I.e. many users of DEVICE_ATTR() are
> > specifying 0400 or 0600 for permissions.
> >
> > Given the expectation that CAP_SYS_ADMIN is needed to access these
> > sensitive attributes and an explicit helper with the _ADMIN_ identifier
> > for DEVICE_ATTR_ADMIN_{RO,RW}.
> >
> > Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > Cc: "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
> > Signed-off-by: Dan Williams <dan.j.williams@...el.com>
> > ---
> >  include/linux/device.h |    4 ++++
> >  include/linux/sysfs.h  |    7 +++++++
> >  2 files changed, 11 insertions(+)
> >
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index 15460a5ac024..d7c2570368fa 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -128,8 +128,12 @@ ssize_t device_store_bool(struct device *dev, struct device_attribute *attr,
> >               __ATTR_PREALLOC(_name, _mode, _show, _store)
> >  #define DEVICE_ATTR_RW(_name) \
> >       struct device_attribute dev_attr_##_name = __ATTR_RW(_name)
> > +#define DEVICE_ATTR_ADMIN_RW(_name) \
> > +     struct device_attribute dev_attr_##_name = __ATTR_RW_MODE(_name, 0600)
> >  #define DEVICE_ATTR_RO(_name) \
> >       struct device_attribute dev_attr_##_name = __ATTR_RO(_name)
> > +#define DEVICE_ATTR_ADMIN_RO(_name) \
> > +     struct device_attribute dev_attr_##_name = __ATTR_RO_MODE(_name, 0400)
> >  #define DEVICE_ATTR_WO(_name) \
> >       struct device_attribute dev_attr_##_name = __ATTR_WO(_name)
> >  #define DEVICE_ULONG_ATTR(_name, _mode, _var) \
> > diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
> > index 86067dbe7745..34e84122f635 100644
> > --- a/include/linux/sysfs.h
> > +++ b/include/linux/sysfs.h
> > @@ -123,6 +123,13 @@ struct attribute_group {
> >       .show   = _name##_show,                                         \
> >  }
> >
> > +#define __ATTR_RW_MODE(_name, _mode) {                                       \
> > +     .attr   = { .name = __stringify(_name),                         \
> > +                 .mode = VERIFY_OCTAL_PERMISSIONS(_mode) },          \
> > +     .show   = _name##_show,                                         \
> > +     .store  = _name##_store,                                        \
> > +}
> > +
> >  #define __ATTR_WO(_name) {                                           \
> >       .attr   = { .name = __stringify(_name), .mode = 0200 },         \
> >       .store  = _name##_store,                                        \
> >
>
> Nice!  Want me to take this now, I know of many other places that could
> be cleaned up to use this (like the raw device bug that I just fixed...)

Sure, that'd be great.

> If not:
>
> Reviewed-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

 Thanks Greg.