Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 741669 - Doesn't seem to be a permission that would allow users to modify own info (password, etc.)
Summary: Doesn't seem to be a permission that would allow users to modify own info (pa...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: WebUI
Version: 6.0.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: Unspecified
Assignee: Justin Sherrill
QA Contact: Katello QA List
URL:
Whiteboard:
Depends On:
Blocks: katello-blockers
TreeView+ depends on / blocked
 
Reported: 2011-09-27 14:36 UTC by Corey Welton
Modified: 2019-09-26 13:21 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-22 17:59:10 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Corey Welton 2011-09-27 14:36:55 UTC 
Description of problem:
I'm not sure there's a permission combination possible that would allow users to change their password.  Note that this isn't a bug re: the fact that there is no UI presently to do such a thing - this is more about the idea that there seems to be no way to configure such a right.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. As admin, Create a user, "nonadmin" with no rights
2. As admin, click the link at the top-right corner to go to what is presumably the placeholder for user info (and probably where a user will be able to change his info) 
3. Login as nonadmin; attempt to visit the user info page - note permission denied.
4. Log back in as admin.  Create a new role, "user_role" and create a global permission called Update Users, which has a permission:verb of User:Update Users
5. Log back in as nonadmin and attempt to navigate to user info page.

Actual results:

This exercise appears to demonstrate that any present/future attempts to grant rights that would allow a user to change his own password (or at very least, view his own user info) are inextricably tied to the a role that grants Update rights across a global (or org-centric) basis - though presumably view user info would be available under Access Users.

Expected results:

There should be a role/permission that allows/will allow users to access their own user info without granting them such access on a larger scale.

Additional info:
Comment 1 Justin Sherrill 2011-10-04 17:57:01 UTC 
added ability for users to edit their own info by clicking on their user name in the upper right hand corner.

030f9e69b377bf3e818237d46256e79fd028c970
Comment 2 Corey Welton 2011-10-06 18:24:37 UTC 
As noted in the initial paragraph above, this bug has little to do with the fact that a user could not modify his or her own personal information - although now having this page makes it more readily apparently.

That said -- creating a user with no roles/permissions cannot access that page. Such a user, when clicking the login name, gets a permission denied.

OTOH, you can grant Update Users perm to this user - but then this user would be have rights to edit users globally or across an organization.

/That/ is the point of this bug. Any ability for a user to edit his or her own information is inextricably tied to a larger role which thus allows update all users, either globally or on an org-by-org basis.
Comment 3 Justin Sherrill 2011-10-06 18:36:02 UTC 
sorry, there was a (mistaken) requirement that to visit that page you needed to be in at least one org.  Fixed:

3ca2afb11c35dff870946754417336ea0860246b
Comment 4 Corey Welton 2011-10-25 04:07:33 UTC 
QA Verified.
Comment 7 Mike McCune 2013-08-16 18:05:46 UTC 
getting rid of 6.0.0 version since that doesn't exist
Note You need to log in before you can comment on or make changes to this bug.