|Summary:||unprivileged user can see Administer -> Bookmarks|
|Product:||Red Hat Satellite||Reporter:||Jan Hutař <jhutar>|
|Component:||Security||Assignee:||Ohad Levy <ohadlevy>|
|Status:||CLOSED ERRATA||QA Contact:||jcallaha|
|Version:||6.1.0||CC:||bbuckingham, bkearney, ehelms, jcallaha, ohadlevy, rplevka, sthirugn|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2016-07-27 08:48:08 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Jan Hutař 2015-02-13 10:11:10 UTC
Description of problem: Unprivileged user can see Administer -> Bookmarks Version-Release number of selected component (if applicable): Satellite-6.1.0-RHEL-6-20150210.0-Satellite-x86_64 How reproducible: always Steps to Reproduce: 1. Login with admin user 2. Switch to "Any context" and create user without any location, org and role 3. Logout with admin user and login with newly created user Actual results: The unprivileged user can access Administer -> Bookmarks. He can not get details about these bookmarks, but see them. Other items user can see - but I do consider them OK: * org/loc switcher which is basically empty and without links to manage org/loc * Monitor with only sub-item Tasks and that page is empty - this probably makes sense as maybe it might happen the unprivileged user have some tasks running (?) * Red Hat Access menu (upper right corner of the page) with "Search", "My Cases" and "Open New Case" which probably makes sense Expected results: IMO whole "Administer" menu should be hidden in this case. Additional info: Noticed while testing bug 1112182
Comment 1 RHEL Program Management 2015-02-13 10:13:42 UTC
Since this issue was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
Comment 3 Tom Caspy 2015-03-19 14:43:38 UTC
well, I believe this is by design, bookmarks are a default permission. Only thing I would change is not putting them under the administer tab, as that makes little sense... PM - what is the expected behaviour?
Comment 4 Bryan Kearney 2015-08-13 16:52:13 UTC
Changing needinfo to ohad.
Comment 5 Ohad Levy 2016-02-22 09:28:31 UTC
Created redmine issue http://projects.theforeman.org/issues/13828 from this bug
Comment 6 Bryan Kearney 2016-02-22 11:00:55 UTC
Upstream bug component is Provisioning
Comment 7 Bryan Kearney 2016-02-22 13:00:55 UTC
Upstream bug component is Security
Comment 8 Bryan Kearney 2016-02-29 15:01:00 UTC
Moving to POST since upstream bug http://projects.theforeman.org/issues/13828 has been closed ------------- Dominic Cleal CVE-2015-7582 has been assigned. Please include the number in the commit message. ------------- Tom Caspy Applied in changeset commit:a61344da14f73920b4bdc7ad8220e7a0ed998031.
Comment 9 Kurt Seifried 2016-03-01 00:43:11 UTC
(In reply to Bryan Kearney from comment #8) > Moving to POST since upstream bug > http://projects.theforeman.org/issues/13828 has been closed > ------------- > Dominic Cleal > CVE-2015-7582 has been assigned. Please include the number in the commit > message. > ------------- > Tom Caspy > Applied in changeset commit:a61344da14f73920b4bdc7ad8220e7a0ed998031. Do you have an idea of which erratum you'll include this in (I assume a point release like 6.1.8?). Thanks.
Comment 10 Bryan Kearney 2016-03-01 07:01:49 UTC
Kurt, this is slated for 6.2
Comment 11 Stephen Benjamin 2016-03-24 19:44:00 UTC
Failed, unprivileged user can still see bookmarks. Created a user with no roles, and logged in. See screenshot. Tried on: 6.2 Snap 5.1
Comment 12 Stephen Benjamin 2016-03-24 19:44:44 UTC
Created attachment 1140106 [details] bookmarks visible to unprivileged user
Comment 14 Ohad Levy 2016-03-31 08:46:56 UTC
this is by design, the bookmarks in the screenshot are all public! you should not see private bookmarks.
Comment 15 Stephen Benjamin 2016-04-04 15:40:35 UTC
Created attachment 1143379 [details] non-public bookmark visible to the user
Comment 16 Stephen Benjamin 2016-04-04 15:40:58 UTC
What is a "public" bookmark? view_bookmarks is a permission to view bookmarks. If a user doesn't have it, they shouldn't see bookmarks at all. It's worth failing QA on this fact alone. However, even under the idea of "public" vs "private" bookmarks, it still fails. I bookmarked a new search as admin, and my unprivileged user could see it (see new screenshot).
Comment 17 Ohad Levy 2016-04-06 08:40:24 UTC
public bookmarks, are public - meaning every user (regardless of permission) will see. private bookmarks are private, and only the current user should see them. you screenshot only shows public bookmarks, which is as designed.
Comment 19 Roman Plevka 2016-04-20 11:05:18 UTC
Stephen, Ohad - perhaps we might prevent confusion by renaming the permission to something like 'view_private_bookmarks'. Otherwise, the current name ('view_bookmarks') really leads to confusion while user without such permission still can see a bookmarks page.
Comment 20 Stephen Benjamin 2016-04-20 13:09:41 UTC
No, I don't think that is the solution and I'd like to hear an argument why if a user doesn't have view_bookmarks, they should still see the menu. No other Satellite object works like this. How do you even create a "private" bookmark? There's zero indication to the user when they create a bookmark from the search bar that's visible to every single person who can login to the Satellite.
Comment 21 Stephen Benjamin 2016-04-20 13:16:29 UTC
I found the answer on my own, there's a public check box that's checked by default. I still say this fails QA, no other object in Satellite works like this and the bug title is literally "unprivileged user can see Administer -> Bookmarks." Lack of view_bookmarks should hide the menu. But if we're just going to have some weird one-off object that doesn't work like anything else, someone else can mark this VERIFIED.
Comment 22 Jan Hutař 2016-04-20 18:49:36 UTC
(In reply to Roman Plevka from comment #19) > Stephen, Ohad - perhaps we might prevent confusion by renaming the > permission to something like 'view_private_bookmarks'. > Otherwise, the current name ('view_bookmarks') really leads to confusion > while user without such permission still can see a bookmarks page. This sounds as a good solution to me. (In reply to Stephen Benjamin from comment #21) > I found the answer on my own, there's a public check box that's checked by > default. Heh, great. I have completely missed that. Thanks for the info!
Comment 23 Stephen Benjamin 2016-04-20 19:34:42 UTC
> This sounds as a good solution to me. It doesn't to me. Every controller in Foreman has a permission that gates access. Why does view_bookmarks mean "private" bookmarks only? A user without 'view_bookmarks' should not see them as an option in search bars, should not see them in menu items, etc. This is how *EVERY* other permission works. I marked this FailedQA in good faith with a good argument for it, but it keeps getting set back to ON_QA without my concern being addressed.
Comment 25 jcallaha 2016-04-28 19:14:46 UTC
Verified in Satellite 6.2 Beta RC. See attached screenshots for the difference between the two. I agree that the current system of having bookmarks be private or public meets the intent of the bug. However, I would recommend a name change for the role.
Comment 29 errata-xmlrpc 2016-07-27 08:48:08 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-2016:1500