Bug 1728523

Summary: non-admin can open create dialog in other namespace
Product: OpenShift Container Platform Reporter: Guohua Ouyang <gouyang>
Component: Management ConsoleAssignee: Samuel Padgett <spadgett>
Status: CLOSED ERRATA QA Contact: Yadan Pei <yapei>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.1.0CC: aos-bugs, cnv-qe-bugs, gouyang, jokerman, mmccomas, ncredi, yapei
Target Milestone: ---   
Target Release: 4.2.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Previously, create buttons and actions would be enabled for all users in the web console, even project viewers who did not have permission to perform those actions. We've now updated the console to either hide or disable those buttons based on the user's access controls.
Story Points: ---
Clone Of:
: 1761041 (view as bug list) Environment:
Last Closed: 2019-10-16 06:33:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
NormalUserViewDefaultPods
none
NormalUserWithoutProjectsViewDefaultPods none

Description Guohua Ouyang 2019-07-10 06:25:41 UTC
Description of problem:
Create a non-admin user, login with the non-admin user and try to access the vm page in a project like 'default'(change the ns in the URL), it can open the vm wizard and yaml dialog. The expectation is user should not be able to open the wizard and yaml in other namespace.

If it's the yaml dialog, the default namespace is 'default', create vm from the yaml will pop up a forbidden error meessage.
If it's the wizard dialog, it can only choose these namespace are available to the current user, continue with the wizard, it can create the vm successfully.

Since user cannot navigate the project which is not available to him, user almost can't hit this issue.

Version-Release number of selected component (if applicable):
HCO-36
kubevirt-web-ui:v2.0.0-14.8
kubevirt:v0.17.4


How reproducible:
100%

Steps to Reproduce:
1. create a non-admin user
2. login the non-admin user on ui
3. change the url to "https://kubevirt-web-ui.apps.working.oc4/k8s/ns/default/virtualmachines"
4. try to open vm wizard

Actual results:
The wizard is opened

Expected results:
Non admin user should not be able to use vm dialog in other namespace.

Additional info:

Comment 5 Samuel Padgett 2019-07-19 10:46:02 UTC
This been addressed in 4.2 by https://github.com/openshift/console/pull/1559

Comment 7 Yadan Pei 2019-07-23 10:10:02 UTC
When a non-admin user views workloads page of other projects via URL such as /k8s/ns/default/pods

An empty page will be returned and you can see `403 (Forbidden)` in F12 dev tools


Does it meet your requirement?

Comment 8 Samuel Padgett 2019-07-23 11:51:10 UTC
When you say empty page, do you mean totally blank or is there a message? The page should not be totally blank.

Comment 9 Guohua Ouyang 2019-07-23 12:19:47 UTC
I don't have an environment to verify this, could you capture a screenshot for it?

Comment 10 Yadan Pei 2019-07-24 01:40:20 UTC
Created attachment 1593038 [details]
NormalUserViewDefaultPods

Comment 11 Yadan Pei 2019-07-24 01:42:00 UTC
Created attachment 1593039 [details]
NormalUserWithoutProjectsViewDefaultPods

Comment 12 Yadan Pei 2019-07-24 01:45:39 UTC
I attached two screenshots

NormalUserViewDefaultPods: When user has a project and view pods in default namespace
NormalUserWithoutProjectsViewDefaultPods: A totally fresh new user view pods in default namespace

I think we should return 403 Forbidden error page instead of a blank page

Comment 13 Samuel Padgett 2019-07-27 17:39:10 UTC
Yadan, can you open a second bug for the issue you're seeing? It's a different problem than the original bug and specific to 4.2. The original RBAC issue with create buttons has been fixed, so we should make sure that's tracked separately and appears in the errata.

Based on my testing, there was a regression during 4.2 development where the pods page is not properly updating when switching projects and receiving the 403 response from the server. The Redux ID with the new project name is not properly getting passed down from Firehose to the Table component.

Also, can you provide exact steps for how you tested this? How you got to the pods page could matter (typing in the URL or navigating to it through the UI).

Comment 14 Guohua Ouyang 2019-07-29 01:38:54 UTC
There is no screenshot about the 'edit' permission, I assume if a user has 'edit' permission, the button 'create pods' is available.
I don't mind to move this bug to 'veified' since the UI objects aren't available to a user who don't have permission to use it.

Comment 15 Yadan Pei 2019-07-29 02:33:18 UTC
(In reply to Samuel Padgett from comment #13)
> Yadan, can you open a second bug for the issue you're seeing? It's a
> different problem than the original bug and specific to 4.2. The original
> RBAC issue with create buttons has been fixed, so we should make sure that's
> tracked separately and appears in the errata.
ok, I will
> 
> Based on my testing, there was a regression during 4.2 development where the
> pods page is not properly updating when switching projects and receiving the
> 403 response from the server. The Redux ID with the new project name is not
> properly getting passed down from Firehose to the Table component.
> 
> Also, can you provide exact steps for how you tested this? How you got to
> the pods page could matter (typing in the URL or navigating to it through
> the UI).
Sure, I will

Moving this bug to VERIFIED since the origin RBAC issue has been fixed:

When a non-admin user views workloads page of other projects via URL such as /k8s/ns/default/pods, an empty page will be returned

No Create buttons

Comment 16 errata-xmlrpc 2019-10-16 06:33:23 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, 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/RHBA-2019:2922