From ${URL} : Franck Grosjean of Red Hat reports: Description of problem: acl definitions are not enforced and could be bypassed by a user without write access to the cib Version-Release number of selected component (if applicable): RedHat Enterprise Linux 6.6 pcs --version = 0.9.123 pacemakerd --version = Pacemaker 1.1.11 How reproducible: a user with a read-only role can assign any other existing roles to himself and then gain any kind of access from any role (rw access to the cib if this kind of role exist). Steps to Reproduce: 1. create a role read-only pcs acl role create read-only description="Read only access" read xpath /cib 2. create a role admin pcs acl role create admin description="Admin access" write xpath /cib 3. create an account (local + pcs) 4. open a session with this roaccount account 5. add admin role to your account pcs acl role assign admin to rocluster 6. check new acl pushed as a read-only user pcs acl User: rocluster Roles: read-only admin Role: read-only Description: Read only access Permission: read xpath /cib (read-only-read) Role: admin Description: Admin access Permission: write xpath /cib (admin-write) 7. add/delete/modify anything Actual results: obtain rw access to the cib Expected results: must not be possible with read-only access to the cib to assign a role Additional info: Introduced in: https://github.com/ClusterLabs/pacemaker/commit/f242c1ef Fixed in: https://github.com/ClusterLabs/pacemaker/commit/84ac07c @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
$ git tag --contains 84ac07c | sort Pacemaker-1.1.13 Pacemaker-1.1.13-rc2 Pacemaker-1.1.13-rc3 Pacemaker-1.1.14 Pacemaker-1.1.14-rc1 Pacemaker-1.1.14-rc2 Pacemaker-1.1.14-rc3 Pacemaker-1.1.14-rc4 Pacemaker-1.1.14-rc5 Pacemaker-1.1.15 Pacemaker-1.1.15-rc1 Pacemaker-1.1.15-rc2 Pacemaker-1.1.15-rc3 Pacemaker-1.1.15-rc4 Pacemaker-1.1.16-rc1 Pacemaker-1.1.16-rc2 Upstream fixed this in v1.1.13. The first version containing the fix which appeared in Gentoo repository was v1.1.14.
This issue was resolved and addressed in GLSA 201710-08 at https://security.gentoo.org/glsa/201710-08 by GLSA coordinator Aaron Bauman (b-man).