Bug 2264825 - [UI][MDR] User-1 can delete application created by user-2
Summary: [UI][MDR] User-1 can delete application created by user-2
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenShift Data Foundation
Classification: Red Hat Storage
Component: odf-dr
Version: 4.15
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ODF 4.15.0
Assignee: Annette Clewett
QA Contact: krishnaram Karthick
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-02-19 06:57 UTC by avdhoot
Modified: 2024-07-18 04:25 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-03-19 15:32:50 UTC
Embargoed:
asagare: needinfo+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Article) 7048456 0 None None None 2024-02-27 11:27:33 UTC
Red Hat Product Errata RHSA-2024:1383 0 None None None 2024-03-19 15:32:52 UTC

Description avdhoot 2024-02-19 06:57:11 UTC
Created attachment 2017600 [details]
delete_screenshot

Description of problem (please be detailed as possible and provide log
snippests):

While testing application users DR operations I found below observation:
user-1 is not able to failover/relocate apps belongs to user-2 which is expected behaviour, but user-1 can delete apps which belongs to user-2.
Also placement and drpc are not deleted.


Is this expected behavior? If yes why?


Version of all relevant components (if applicable):
OCPO-4.15.0
ODF- 4.15.0
ACM- 2.9.1
ceph- 7.1


Does this issue impact your ability to continue to work with the product
(please explain in detail what is the user impact)?


Is there any workaround available to the best of your knowledge?


Rate from 1 - 5 the complexity of the scenario you performed that caused this
bug (1 - very simple, 5 - very complex)?


Can this issue reproducible?
yes

Can this issue reproduce from the UI?
Yes

If this is a regression, please provide more details to justify this:


Steps to Reproduce:
1. Create user-1 by referring[1]
2. Deploy subscription and appset app using user-1
3. Assign DR policy
4. Create user-2 by referring[1]
5. Deploy subscription and appset app using user-2
6. Assign DR policy.
7. Trey to delete application created by user-2 by using user-1.
8. Application get deleted. 

[1]https://access.redhat.com/articles/7048456 

Actual results:
Application get deleted.

Expected results:
Application should not delete by using other user.

Additional info:

Comment 3 Annette Clewett 2024-02-19 18:33:07 UTC
This is most likely due to giving user clusterrolebinding to subscription-admin privileges in KCS https://access.redhat.com/articles/7048456. 

Subscriptions:
$ oc create clusterrolebinding {role-binding-name} --clusterrole=open-cluster-management:subscription-admin --user={username}

Need to see if it is possible for user to create subscription with rolebinding for only user created namespaces.

Like this after user creates <user_created_new_namespace>:

oc create rolebinding {role-binding-name} -n <user_created_new_namespace> --clusterrole=open-cluster-management:subscription-admin --user={username}

If not is there any way to limit privileges so that user cannot deleted another user's applications?

Comment 4 Xiangjing Li 2024-02-21 17:04:07 UTC
For now the hub subscription controller only searches all clusterRoleBinding kind resources to see if the appsub user/group is bound to the open-cluster-management:subscription-admin  clusterRole.  It doesn't check rolebinding kind resources in all namespaces, which could be a expensive behaviour

the non-cluster-admin user still can create a appsub application even though it is not a subscription-admin.  So for non-subscription-admin user, all the app resources are enforced to deploy to the appsub NS
While for subscription-admin user, all app resources can be deployed to other NS defined in the git repo

FYI @rjung @ming 

Feel free to chime in to see if we should support this case - decide if the user is subscription admin by checking clusterrolebinding kind and rolebinding kind resources in all namespaces

Comment 9 avdhoot 2024-02-28 10:17:51 UTC
Hi Annette,

I gone through the new content in kcs as well as tried procedure.

During execution I feel new process is little complex and time consuming. 
How we are doing it at large scale?

Because I feel that When Customer has number application as appuser,they might fill it very long and tedious process.
Specially for:
1. "RoleBinding for every project project"
2. Creating channel and channel-namespace for every application repo and rolebinding for channel NS.

Please let me know your thoughts.

Comment 11 avdhoot 2024-02-29 14:16:25 UTC
Yes the new process successful in KCS https://access.redhat.com/articles/7048456.

Version:
OCP: 4.15.0
ODF: 4.15.0-RC
ACM:2.10.0-77

Observations:
1. User 1 not able to see application sof user 2.
2. User can faiover and relocate application.
3. Need correct output shown in step 13 with below output. i.e. ClusterRole/roleuseracm is added.

➜  hub oc get rolebindings.rbac.authorization.k8s.io -n bb-redhat
NAME                       ROLE                               AGE
admin                      ClusterRole/admin                  10m
rolebindinguseracmredhat   ClusterRole/roleuseracm            3m18s
system:deployers           ClusterRole/system:deployer        10m
system:image-builders      ClusterRole/system:image-builder   10m
system:image-pullers       ClusterRole/system:image-puller    10m

Comment 12 Annette Clewett 2024-02-29 16:06:38 UTC
@asagare thank you for verifying KCS new instructions. The correction in Observation #3 has been fixed and published in KCS https://access.redhat.com/articles/7048456.

Comment 17 errata-xmlrpc 2024-03-19 15:32:50 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: Red Hat OpenShift Data Foundation 4.15.0 security, enhancement, & bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2024:1383

Comment 18 Red Hat Bugzilla 2024-07-18 04:25:33 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days


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