Hide Forgot
Description of problem: In Horizon, when going to Manila and then clicking 'share' then 'share network' without admin privileges, the user will be logged out How reproducible: Every time Steps to Reproduce: 1. Log in to Horizon as user without admin privileges 2. Go to Manila -> Share 3. Click 'Share network' button Actual results: The user is logged out Expected results: The button is unclickable Additional info: This behavior is very similar to https://bugzilla.redhat.com/show_bug.cgi?id=1326146
Trying to reproduce this I am unable to. Using: horizon: Red Hat Kilo branch manila-ui: Kilo branch manila installed from packstack: Name : openstack-manila Arch : noarch Version : 2015.1.0 Release : 2.el7ost Created a new tenant "test" Created a new user "test" member of tenant "test" Logged in as "test" user Went to "Shares" -> "Share networks" Added a new "Share Network" Also I created several shares and deleted them, went all over the shares menus/buttons/tabs but could not trigger this issue. Can we got more logs or a more detailed walktrougth on how to trigger this? Seems like Im missing something, for example: I dont have a manila -> shares submenu on RHOS7. My "Shares" item is in the compute part directly. I dont really understand which one is the 'Share network' button. Is that a tab? Is that the "Create Share Network" button? Can I get a screenshot of it please? Thanks!
Hello sir, If you go back in the "Share" -> "Share networks" and click on any of the shared networks, it will log you out if the user doesn't have the admin role. Thank you very much, David Hill
This is a manila-ui issue, althougth the origin can be pointed to horizon, it has to be fixed on the manila-ui project. Just to be clear, the issue is very simple. User has a list of share networks and each share network has a link in the name to see the details of the share. But when clicking on it, the user is facing with an error. This is due to the normal user not having enough privileges to view that share details. The way this was fixed on horizon on the patch mentioned in the bug was to check for user privileges _before_ adding the link, thus no privileges, no link. Unfortunately, after a couple of tests I cannot apply the same patch style to manila-ui, as the policy checks for permission pass, but in the end is the manila service the one that denies the user access to those details, so it looks like something else is wrong (policy check maybe). A very simple workaround for this (tested myself locally) is to edit the manila /etc/manila/policy.json file and change: "share_server:index": [["rule:admin_api"]], to: "share_server:index": [["rule:default"]], And restart manila services (share, scheduler, api) Would this be good enough as a workaround for them?
Is it right to state, the proposed change does NOT require any change in Horizon? Is that the solution? If it's a manila setup issue, then the bug should be either on manila component or on the installer, right?
As noted in comment 6 this can be worked around via a config change in the manilla policy.json thus moving to manilla-ui. If this is something that should be addressed in osp-d please go ahead and move it there. Thanks!
Moving to openstack-manila, the policy file belongs to manila, not manila-ui.
removing the needinfo
Created attachment 1221628 [details] screen shot of horizon following reproduction steps as unprivileged demo user
This bug was filed for a tech-preview release (OSP-7) and has a workaround (see https://bugzilla.redhat.com/show_bug.cgi?id=1330713#c6). We kept it open to make sure that we checked the first GA release, OSP-10, to see if the issue persisted and if so, fix it there. I've deployed with a current OSP-10 puddle via OSP-D, created a non-privileged demo user, logged into horizon running in the deployment as the demo user, and am not able to reproduce the issue following the steps in the description. See https://bugzilla.redhat.com/attachment.cgi?id=1221628 where I've progressed as user demo through Share -> Share Network to Share -> Share Network -> Create Share Network without any issue. There's nothing to fix here so I'm going to close this one out.