Bug 1466428 - incorrect default permissions of user belonging to group haclient
incorrect default permissions of user belonging to group haclient
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pcs (Show other bugs)
7.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Tomas Jelinek
cluster-qe@redhat.com
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-29 10:39 EDT by Josef Zimek
Modified: 2017-07-21 06:02 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1466722 (view as bug list)
Environment:
Last Closed: 2017-07-21 06:02:21 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Josef Zimek 2017-06-29 10:39:15 EDT
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 11:00:40 EDT
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 11:39:25 EDT
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 06:26:48 EDT
Described pcs/pcsd behavior is expected.

I filed bz1466722 to fix the documentation.
Comment 6 John Ruemker 2017-07-12 16:14:28 EDT
(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 03:55:40 EDT
I am fine with closing this as NOTABUG. Josef, how about you?
Comment 9 Tomas Jelinek 2017-07-21 06:02:21 EDT
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.