I have no inclination whether this deserves to be implemented, just want
to point out a disparity between pacemaker native functionality and what
pcs interface, being the main entry point to it, facilitates.

I will link this very bug to informative/warning messages about the
native syntactic sugar for ACL permissions that is, so far, not
supported by pcs (see below) in the new ACL handling of clufter when
outputting "sequence of pcs commands", meant to resolve [bug 1440876].

So what's missing on pcs side and how can it be mimicked through
hard-core "xpath" argument encoding a subject of ACL permission
(this is what pacemaker actually does under the hood) as in
"pcs acl {permission add,role create}":

1. "reference", could be passed as "reference FOO" & can be mimicked
   as "xpath //*[@id='FOO']"

2. "object-type", could be passed as "object-type FOO [attr BAR]"
   & can be mimicked as "xpath //FOO", with the optional part as
   "xpath //FOO[BAR]"

Note that especially 1. can be pretty handy: consider the scenario
in which the main cluster admin is OK to provide read-only CIB data
to non-cluster-assigned admins (say under "observer" user account),
except for a few password-carrying nvpair items with clearly assigned
IDs, say "my-fd-passwd" for our purpose.  It would be nice if she could
just, for instance:

> pcs acl role create no-fd-passwd deny reference my-fd-passwd
> pcs role assign no-fd-passwd to user observer

i.e., without getting in touch with anything like XPath expressions,
contrary to:

> pcs acl role create no-fd-passwd deny xpath "//*[@id='my-fd-passwd']"

(not to speak about extra precaution because of implicit shell pattern
matching/glob'ing that pretty much applies here).

Thanks for considering.


+++ This bug was initially created as a clone of Bug #1111369 +++

Support for viewing/creating/editing pacemaker ACLs is needed.