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:
This been addressed in 4.2 by https://github.com/openshift/console/pull/1559
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?
When you say empty page, do you mean totally blank or is there a message? The page should not be totally blank.
I don't have an environment to verify this, could you capture a screenshot for it?
Created attachment 1593038 [details] NormalUserViewDefaultPods
Created attachment 1593039 [details] NormalUserWithoutProjectsViewDefaultPods
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
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).
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.
(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
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