Bug 1440890 - support ACL roles with "object-type" and "attribute" attributes
Summary: support ACL roles with "object-type" and "attribute" attributes
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pcs
Version: 7.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Tomas Jelinek
QA Contact: cluster-qe@redhat.com
Depends On: 1111369
TreeView+ depends on / blocked
Reported: 2017-04-10 16:57 UTC by Jan Pokorný [poki]
Modified: 2020-04-02 16:03 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1111369
Last Closed:
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1440876 None CLOSED Support Pacemaker ACLs 2019-08-30 08:37:11 UTC

Internal Links: 1440876

Description Jan Pokorný [poki] 2017-04-10 16:57:24 UTC
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.

Comment 1 Jan Pokorný [poki] 2017-04-10 17:03:22 UTC
Correction (showing, by the way, how tricky it is to get XPath routinely

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]  <-- at-sign was missing

Comment 2 Tomas Jelinek 2017-04-11 07:37:11 UTC
(In reply to Jan Pokorný from comment #0)
> 1. "reference", could be passed as "reference FOO" & can be mimicked
>    as "xpath //*[@id='FOO']"

already implemented:
pcs acl role create no-fd-passwd deny id my-fd-passwd

> 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]"

This is indeed missing in pcs.

pcs does not support ACL roles with "object-type" and "attribute" attributes.

Comment 3 Jan Pokorný [poki] 2017-04-11 09:11:10 UTC
re [comment 2]:
Indeed, this was an oversight on my side, simply because how confusing
the situation is bottom-up (pacemaker code, through two not entirely
compatible approaches schema-wise, to terminology used in pcs).

I have to wonder if 2. was ever meaningful, simply because common nvpairs
encoding of dictionary-like data is not reachable with this provision,
and there's not much left beyond that, what could be of interest.

Comment 4 Jan Pokorný [poki] 2017-04-11 09:16:40 UTC
re [comment 3]:
I meant mostly the "attribute" part, "object-type" on its own can still
be useful, simply because the main tags like "configuration" go without
IDs and are unique on its own (enforced by the schema).

Note You need to log in before you can comment on or make changes to this bug.