Bug 1722970

(In reply to Ken Gaillot from comment #0)
> * RFE: The acl command doesn't support pacemaker's object-type and attribute
> options for acl_permission. xpath can do the same thing, so perhaps we
> intentionally don't want to, but in case we do: object-type is the name of
> an XML element in the CIB to which the permission applies, and if attribute
> (which may optionally and only be used with object-type) is specified, only
> elements of object-type that have that attribute set (to any value) will be
> selected.

covered by bz1440890

> * Not related to the acl command per se, but pcs resource ban and friends
> will print the "Creating rsc_location constraint" warning even if the change
> is actually rejected by ACLs. There may be other similar cases I didn't run
> into.

should be fixed by pcs printing messages coming from crm_mon instead of inventing its own (already done in pcs)

Considering the above this bz is just usage / man page change.

(In reply to Ken Gaillot from comment #0)
> * One crucial distinction the help should mention: xpaths may include
> attributes to help select certain elements, but the permission applies to
> the entire element (and its subtree), not to the attribute alone. That is to

This sentence feels weird to me: xpaths may ... select certain _elements_, but the permission applies to the entire _element_...
Should it say: "to help select certain attributes" or maybe "to help select certain elements' attributes" instead?

> say, you can't define an ACL that allows someone to read just the dc-uuid
> attribute of the cib tag -- that would select the cib element and give read
> access to the entire CIB.

(In reply to Tomas Jelinek from comment #7)
> (In reply to Ken Gaillot from comment #0)
> > * One crucial distinction the help should mention: xpaths may include
> > attributes to help select certain elements, but the permission applies to
> > the entire element (and its subtree), not to the attribute alone. That is to
> 
> This sentence feels weird to me: xpaths may ... select certain _elements_,
> but the permission applies to the entire _element_...
> Should it say: "to help select certain attributes" or maybe "to help select
> certain elements' attributes" instead?

Maybe: An xpath may include an attribute expression to select only elements that match the expression, but the permission still applies to the entire element (and its subtree), not to the attribute alone.

E.g. using the xpath "//*[@name]" to give write permission would allow changes to the entirety of all elements that have a "name" attribute and everything enclosed by those elements, not just changes to the "name" attribute. There's no way currently to give permissions for just one attribute of an element.

> > say, you can't define an ACL that allows someone to read just the dc-uuid
> > attribute of the cib tag -- that would select the cib element and give read
> > access to the entire CIB.

Created attachment 1669883 [details]
proposed fix

Documentation updated, see previous comments, no tests included.

Patch is in the bulid.

[root@r8-node-01 pcs]# rpm -q pcs
pcs-0.10.6-1.el8.x86_64

[root@r8-node-01 pcs]# pcs acl role create --help

Usage: pcs acl role create...
    role create <role id> [description=<description>]
            [((read | write | deny) (xpath <query> | id <id>))...]
        Create a role with the id and (optional) description specified. Each
        role can also have an unlimited number of permissions (read/write/deny)
        applied to either an xpath query or the id of a specific element in the
        CIB.

        Permissions are applied to the selected XML element's entire XML
        subtree (all elements enclosed within it). Write permission grants the
        ability to create, modify, or remove the element and its subtree, and
        also the ability to create any "scaffolding" elements (enclosing
        elements that do not have attributes other than an ID). Permissions for
        more specific matches (more deeply nested elements) take precedence
        over more general ones. If multiple permissions are configured for the
        same match (for example, in different roles applied to the same user),
        any deny permission takes precedence, then write, then lastly read.

        An xpath may include an attribute expression to select only elements
        that match the expression, but the permission still applies to the
        entire element (and its subtree), not to the attribute alone. For
        example, using the xpath "//*[@name]" to give write permission would
        allow changes to the entirety of all elements that have a "name"
        attribute and everything enclosed by those elements. There is no way
        currently to give permissions for just one attribute of an element.
        That is to say, you can not define an ACL that allows someone to read
        just the dc-uuid attribute of the cib tag - that would select the cib
        element and give read access to the entire CIB.

BEFORE:
=======

[root@virt-044 ~]# rpm -q pcs
pcs-0.10.4-6.el8.x86_64


## man page

[root@virt-044 ~]# man pcs | grep "role  create" -A 5
       role  create  <role id> [description=<description>] [((read | write | deny) (xpath <query> | id
       <id>))...]
              Create a role with the id and (optional) description specified.  Each role can also have
              an unlimited number of permissions (read/write/deny) applied to either an xpath query or
              the id of a specific element in the cib.


[root@virt-044 ~]# man pcs | grep "permission add" -A 2
       permission add <role id> ((read | write | deny) (xpath <query> | id <id>))...
              Add the listed permissions to the role specified.


## acl usage

[root@virt-044 ~]# pcs acl --help | grep "role create" -A 6
    role create <role id> [description=<description>] [((read | write | deny)
                                                (xpath <query> | id <id>))...]
        Create a role with the id and (optional) description specified.
        Each role can also have an unlimited number of permissions
        (read/write/deny) applied to either an xpath query or the id
        of a specific element in the cib.


[root@virt-044 ~]# pcs acl --help | grep "permission add" -A 3
    permission add <role id> ((read | write | deny) (xpath <query> |
                                                                id <id>))...
        Add the listed permissions to the role specified.


AFTER:
======

[root@virt-125 ~]# rpm -q pcs
pcs-0.10.6-3.el8.x86_64


## man page

[root@virt-125 ~]# man pcs | grep "role  create" -A 21
       role  create  <role id> [description=<description>] [((read | write | deny) (xpath <query> | id
       <id>))...]
              Create a role with the id and (optional) description specified. Each role can also  have
              an unlimited number of permissions (read/write/deny) applied to either an xpath query or
              the id of a specific element in the cib.
              Permissions are applied to the selected XML element's entire XML subtree  (all  elements
              enclosed  within  it).  Write permission grants the ability to create, modify, or remove
              the element and its subtree, and also the ability to create any  "scaffolding"  elements
              (enclosing  elements that do not have attributes other than an ID). Permissions for more
              specific matches (more deeply nested elements) take precedence over more  general  ones.
              If  multiple  permissions  are  configured for the same match (for example, in different
              roles applied to the same user), any deny permission takes precedence, then write,  then
              lastly read.
              An  xpath  may  include  an  attribute expression to select only elements that match the
              expression, but the permission still applies to the entire element  (and  its  subtree),
              not to the attribute alone. For example, using the xpath "//*[@name]" to give write per‐
              mission would allow changes to the entirety of all elements that have a "name" attribute
              and everything enclosed by those elements. There is no way currently to give permissions
              for just one attribute of an element. That is to say, you can not  define  an  ACL  that
              allows someone to read just the dc-uuid attribute of the cib tag - that would select the
              cib element and give read access to the entire CIB.


[root@virt-125 ~]# man pcs | grep "permission add" -A 19
       permission add <role id> ((read | write | deny) (xpath <query> | id <id>))...
              Add  the  listed permissions to the role specified. Permissions are applied to either an
              xpath query or the id of a specific element in the CIB.
              Permissions are applied to the selected XML element's entire XML subtree  (all  elements
              enclosed  within  it).  Write permission grants the ability to create, modify, or remove
              the element and its subtree, and also the ability to create any  "scaffolding"  elements
              (enclosing  elements that do not have attributes other than an ID). Permissions for more
              specific matches (more deeply nested elements) take precedence over more  general  ones.
              If  multiple  permissions  are  configured for the same match (for example, in different
              roles applied to the same user), any deny permission takes precedence, then write,  then
              lastly read.
              An  xpath  may  include  an  attribute expression to select only elements that match the
              expression, but the permission still applies to the entire element  (and  its  subtree),
              not to the attribute alone. For example, using the xpath "//*[@name]" to give write per‐
              mission would allow changes to the entirety of all elements that have a "name" attribute
              and everything enclosed by those elements. There is no way currently to give permissions
              for just one attribute of an element. That is to say, you can not  define  an  ACL  that
              allows someone to read just the dc-uuid attribute of the cib tag - that would select the
              cib element and give read access to the entire CIB.


## acl usage

[root@virt-125 ~]# pcs acl --help | grep "role create" -A 27
    role create <role id> [description=<description>]
            [((read | write | deny) (xpath <query> | id <id>))...]
        Create a role with the id and (optional) description specified. Each
        role can also have an unlimited number of permissions (read/write/deny)
        applied to either an xpath query or the id of a specific element in the
        CIB.

        Permissions are applied to the selected XML element's entire XML
        subtree (all elements enclosed within it). Write permission grants the
        ability to create, modify, or remove the element and its subtree, and
        also the ability to create any "scaffolding" elements (enclosing
        elements that do not have attributes other than an ID). Permissions for
        more specific matches (more deeply nested elements) take precedence
        over more general ones. If multiple permissions are configured for the
        same match (for example, in different roles applied to the same user),
        any deny permission takes precedence, then write, then lastly read.

        An xpath may include an attribute expression to select only elements
        that match the expression, but the permission still applies to the
        entire element (and its subtree), not to the attribute alone. For
        example, using the xpath "//*[@name]" to give write permission would
        allow changes to the entirety of all elements that have a "name"
        attribute and everything enclosed by those elements. There is no way
        currently to give permissions for just one attribute of an element.
        That is to say, you can not define an ACL that allows someone to read
        just the dc-uuid attribute of the cib tag - that would select the cib
        element and give read access to the entire CIB.


[root@virt-125 ~]# pcs acl --help | grep "permission add" -A 26
    permission add <role id>
            ((read | write | deny) (xpath <query> | id <id>))...
        Add the listed permissions to the role specified. Permissions are
        applied to either an xpath query or the id of a specific element in the
        CIB.

        Permissions are applied to the selected XML element's entire XML
        subtree (all elements enclosed within it). Write permission grants the
        ability to create, modify, or remove the element and its subtree, and
        also the ability to create any "scaffolding" elements (enclosing
        elements that do not have attributes other than an ID). Permissions for
        more specific matches (more deeply nested elements) take precedence
        over more general ones. If multiple permissions are configured for the
        same match (for example, in different roles applied to the same user),
        any deny permission takes precedence, then write, then lastly read.

        An xpath may include an attribute expression to select only elements
        that match the expression, but the permission still applies to the
        entire element (and its subtree), not to the attribute alone. For
        example, using the xpath "//*[@name]" to give write permission would
        allow changes to the entirety of all elements that have a "name"
        attribute and everything enclosed by those elements. There is no way
        currently to give permissions for just one attribute of an element.
        That is to say, you can not define an ACL that allows someone to read
        just the dc-uuid attribute of the cib tag - that would select the cib
        element and give read access to the entire CIB.

> OK: The usage / man ('role created' and 'permission add') page of acl is improved by mentioning the precedence of permissions and specifying usage of xpath


Marking as VERIFIED for pcs-0.10.6-3.el8

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (pcs bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:4617