RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1722970 - Improve pcs acl usage
Summary: Improve pcs acl usage
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: pcs
Version: 8.0
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: rc
: 8.0
Assignee: Tomas Jelinek
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-21 21:07 UTC by Ken Gaillot
Modified: 2020-11-04 02:33 UTC (History)
7 users (show)

Fixed In Version: pcs-0.10.6-1.el8
Doc Type: Bug Fix
Doc Text:
Pcs built-in help and man page were updated to explain in more details how pacemaker ACLs work.
Clone Of:
Environment:
Last Closed: 2020-11-04 02:28:16 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
proposed fix (9.68 KB, patch)
2020-03-13 10:02 UTC, Tomas Jelinek 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2020:4617 0 None None None 2020-11-04 02:28:37 UTC

Description Ken Gaillot 2019-06-21 21:07:26 UTC 
Description of problem: While testing and documenting pacemaker ACLs upstream, I found some minor issues with pcs's acl command:

* The help doesn't say anything about the precedence of permissions. Here's what I'm planning for upstream: "Permissions are applied to the selected XML element's entire XML subtree (all elements enclosed within it). 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." (The first sentence is the most important -- users may not realize that granting access to one element also grants access to everything inside it.)

* The help doesn't say anything about what an xpath is. It's easily googleable, so maybe that's OK, but we could include a link to some documentation. The official reference is https://www.w3.org/TR/xpath-10/ but it's rather difficult to read. I don't know if we have an access article or some such that would be better.

* 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 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.

* 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.

* 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.

Feel free to separate this into multiple BZs if desired.
Comment 1 Tomas Jelinek 2019-08-19 10:48:07 UTC 
(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)
Comment 2 Tomas Jelinek 2019-08-19 10:50:05 UTC 
Considering the above this bz is just usage / man page change.
Comment 7 Tomas Jelinek 2020-03-06 16:24:55 UTC 
(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.
Comment 8 Ken Gaillot 2020-03-06 16:39:23 UTC 
(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.
Comment 9 Tomas Jelinek 2020-03-13 10:02:01 UTC 
Created attachment 1669883 [details]
proposed fix

Documentation updated, see previous comments, no tests included.
Comment 11 Miroslav Lisik 2020-06-11 14:10:49 UTC 
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.
Comment 14 Michal Mazourek 2020-07-29 11:37:43 UTC 
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
Comment 17 errata-xmlrpc 2020-11-04 02:28:16 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.