Description of problem:
Unprivileged user can see Administer -> Bookmarks
Version-Release number of selected component (if applicable):
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
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
* Red Hat Access menu (upper right corner of the page) with "Search",
"My Cases" and "Open New Case" which probably makes sense
IMO whole "Administer" menu should be hidden in this case.
Noticed while testing bug 1112182
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
CVE-2015-7582 has been assigned. Please include the number in the commit message.
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
> 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
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]
Created attachment 1152045 [details]
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.