Bug 1192414
| 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 | ||||||||||
| Severity: | medium | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 6.1.0 | CC: | bbuckingham, bkearney, ehelms, jcallaha, ohadlevy, rplevka, sthirugn | ||||||||||
| Target Milestone: | Unspecified | Keywords: | Triaged | ||||||||||
| Target Release: | Unused | ||||||||||||
| Hardware: | Unspecified | ||||||||||||
| OS: | Unspecified | ||||||||||||
| URL: | http://projects.theforeman.org/issues/13828 | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2016-07-27 08:48:08 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: | |||||||||||||
| Bug Depends On: | |||||||||||||
| Bug Blocks: | 1310675 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Jan Hutař
2015-02-13 10:11:10 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. 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? Changing needinfo to ohad. Created redmine issue http://projects.theforeman.org/issues/13828 from this bug Upstream bug component is Provisioning Upstream bug component is Security 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. (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. Kurt, this is slated for 6.2 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 Created attachment 1140106 [details]
bookmarks visible to unprivileged user
this is by design, the bookmarks in the screenshot are all public! you should not see private bookmarks. Created attachment 1143379 [details]
non-public bookmark visible to the user
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). 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. 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.
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. 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. (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! > 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.
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. Created attachment 1152044 [details]
privileged
Created attachment 1152045 [details]
un-privileged
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 |