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 1466428 - incorrect default permissions of user belonging to group haclient
Summary: incorrect default permissions of user belonging to group haclient
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pcs
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Tomas Jelinek
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-06-29 14:39 UTC by Josef Zimek
Modified: 2020-09-10 10:48 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1466722 (view as bug list)
Environment:
Last Closed: 2017-07-21 10:02:21 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Josef Zimek 2017-06-29 14:39:15 UTC 
Description of problem:

As per our documentation any user which belongs into group haclient should be able to perform cluster changes:


"By default, the root user and any user who is a member of the group haclient has full read/write access to the cluster configuration."

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/High_Availability_Add-On_Reference/index.html#s1-accesscontrol-HAAR


This doesn't seem to be the case as newly created user which belongs to group haclient cannot perform certain activities such as stopping cluster on a node.

It seems that "grant" permission is not set by default


Version-Release number of selected component (if applicable):
pcs-0.9.152-10.el7_3.3.x86_64
pacemaker-1.1.15-11.el7_3.4.x86_64


How reproducible:
Always 

Steps to Reproduce:

# adduser rouser

# passwd rouser

# usermod -a -G haclient rouser

# su - rouser

$ id rouser
uid=1002(rouser) gid=1002(rouser) groups=1002(rouser),189(haclient)

$ pcs acl
ACLs are disabled, run 'pcs acl enable' to enable


$ pcs cluster stop --all
virt-138: virt-138: Permission denied - (HTTP error: 403)
virt-139: virt-139: Permission denied - (HTTP error: 403)

Error: unable to stop all nodes
virt-138: virt-138: Permission denied - (HTTP error: 403)
virt-139: virt-139: Permission denied - (HTTP error: 403)


Actual results:
new user from group haclient cannot operate cluster (`pcs status works`, `pcs cluster stop` not)

Expected results:
users from group haclient can modify cluster



Additional info:

this workaround works for me:

1) Go to pcsd UI: https://<cluster-node-hostname>:2224

2) Login as hacluster user

3) Go to "Permissions" tab

4) Add user "full-access-user" and select desired permissions - read/write/grant/full (full means that user can even add/remove nodes to/from cluster)

5) Save (apply change)

6) Test the rouser with `pcs cluster <whatever>`
Comment 3 Tomas Jelinek 2017-06-29 15:00:40 UTC 
ACLs have no effect on cluster stop, so they are irrelevant here.

The default permissions are set for the haclient group not individual users. It 
does not matter when a user becomes a member of the haclient group.

What is relevant here are the permissions set in pcsd, which can be managed in pcsd gui in the permissions tab. And we do not know what permissions are set. So far this looks to me the permissions for the haclient group has been removed and then the described behavior is expected.

If a user is add to the haclient group when the group has no permissions, the user itself has no permissions either.
Comment 4 Tomas Jelinek 2017-06-29 15:39:25 UTC 
This is what is going on:

If a cluster has been created with pcs which has not support for permissions then pcs automatically grants "read", "write" and "grant" permissions to the haclient group in order to maintain backward compatibility with how things were configured before pcs upgrade. It does not grant "full" permissions which are required for example for adding new nodes to a cluster.

If a cluster is created with pcs which supports permissions, no permissions are granted to the haclient group. Therefore only the hacluster user is allowed to execute commands where pcsd permissions apply, "pcs cluster stop" being one of them.
Comment 5 Tomas Jelinek 2017-06-30 10:26:48 UTC 
Described pcs/pcsd behavior is expected.

I filed bz1466722 to fix the documentation.
Comment 6 John Ruemker 2017-07-12 20:14:28 UTC 
(In reply to Tomas Jelinek from comment #4)
> This is what is going on:
> 
> If a cluster has been created with pcs which has not support for permissions
> then pcs automatically grants "read", "write" and "grant" permissions to the
> haclient group in order to maintain backward compatibility with how things
> were configured before pcs upgrade. It does not grant "full" permissions
> which are required for example for adding new nodes to a cluster.
> 
> If a cluster is created with pcs which supports permissions, no permissions
> are granted to the haclient group. Therefore only the hacluster user is
> allowed to execute commands where pcsd permissions apply, "pcs cluster stop"
> being one of them.

So, CLOSED NOTABUG?  Or was there anything else we need to do here?
Comment 7 Tomas Jelinek 2017-07-13 07:55:40 UTC 
I am fine with closing this as NOTABUG. Josef, how about you?
Comment 9 Tomas Jelinek 2017-07-21 10:02:21 UTC 
Closing according to comment 4 and bug 1466722 comment 10
Note You need to log in before you can comment on or make changes to this bug.