Bug 797412
Summary: | katello permission not working as expected | ||
---|---|---|---|
Product: | Red Hat Satellite | Reporter: | Forrest Taylor <ftaylor> |
Component: | Content Management | Assignee: | Partha Aji <paji> |
Status: | CLOSED ERRATA | QA Contact: | Kedar Bidarkar <kbidarka> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 6.0.0 | CC: | achan, bkearney, cpelland, dmacpher, gkhachik, lzap, omaciel, paji |
Target Milestone: | Unspecified | Keywords: | Triaged |
Target Release: | Unused | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: |
Creating users with roles and permissions through the command line results in incorrect permissions. The command line used environment names as input parameters instead of identification. This fix adds a "search" route to the environment controllers and checks if the user has permissions to commit actions in that environment. Permissions now assign correctly for users created on the command line.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2012-12-04 19:42:31 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Forrest Taylor
2012-02-25 17:22:39 UTC
Reproducing... Hello, so the first example - it seems creating changeset management permission does not give organization read permission. If you give it, it works. This is a bug I guess. The second example is not a bug. Once you have create permission, you automatically get a delete permission. This is how it is implemented in the whole Katello. I have to admit we should indicate this somehow or maybe UI could automatically assign also delete permission when create is added. But this is another story (feel free to file a low severity post V1 bug) @Partha/Justin - I want to fix the first example but I would like to ask. The CLI needs to get list of environments first, so the rule for this is: index_rule = lambda{@organization.readable? || @organization.any_systems_registerable?} Obviously this is not working and what I need to add somewhere is this: def self.any_changesets_readable? org User.allowed_to?(CHANGE_SETS_READABLE, :environments, nil, org) end The question (A) is where? KTEnvironment seems like a good candidate, but there is already very similar method there: def self.any_contents_readable? org, skip_library=false ids = org.environment_ids ids = ids - [org.library.id] if skip_library User.allowed_to?(CONTENTS_READABLE, :environments, ids, org, true) end The only exception is it is checking for content and it does not provide "nil" for the tags, but list of existing environments ids. My second question (B) is why you do this in "any_*" method here. I was under impression that "any_*" methods looks for "any" tags - I mean for permissions that has "nil" set (no tags). We hit this in the CLI because we are stateless and we sometime need to do additional queries (like fetch avaiable environments) before actual (main) request. By the way this is a generic bug - it was able to reproduce it for: - templates - activation keys Command git grep get_environment in the cli shows also (need to do a check-up): - errata - product - repo Last question (C) is what CONTENTS_READABLE represents? Providers? Packages? Which kind of content? Thanks. So part of the solution for at least the second example is to rename the verbs to make em more descriptive and consistent with the UI.. My recommendation is to s/create/administer s/manage_all/administer s/update/modify Hopefully that 'll make it clearer that :administer implies CRUD. Other A) Your question on putting the changesets readable on self.any_contents_readable?. I m not sure thats a good idea. Roughly when did the UI perms review.. Go to UI promotions page. The stuff on the left pane where we show the tree of Products/Repos/Packages/Templates/Errata/Distros, thats based of Contents readable permission. The suff on the right Changesets is based of the changeset readable permission. So things like read changesets or promote_changesets are specific to changesets. To technically be able to add things to a changeset you need both edit on changesets + contents_readable persmission on the environment. (B) def self.any_contents_readable? org, skip_library=false ids = org.environment_ids ids = ids - [org.library.id] if skip_library User.allowed_to?(CONTENTS_READABLE, :environments, ids, org, true) end why you do this in "any_*" method here. I was under impression that "any_*" methods looks for "any" tags - I mean for permissions that has "nil" set (no tags). I presume we want it to check if this user can read any environment in specific org and even there we may want to skip org library. So idea is that last flag set to true will say "return true if the query passes for any of the tags I passed in". That being said if you have all tags set to true , which should/will automatically happen when you created a "global" permission, this should automatically pass since this check happens ahead of the 2nd query. We needed to add that last flag of true User.allowed_to?(CONTENTS_READABLE, :environments, ids, org, true) for exactly cases like this. By default if you passed in a list of tags, the query will return true only if ALL the tags you passed in match . In our case we really don;t need to check for all tags.. We just need the answer for the question , "can the user access contents atleast one environment in this org?" (C) is what CONTENTS_READABLE represents? Providers? Packages? Which kind of content? look at A. Thanks for info, let me know if you hit any issues with our CLI when changing it. In the first example, when I add read permissions for the organization: # katello -u admin -p admin permission create --user_role Changeset_manager \ --name Read_orgs --scope organizations --verbs read I can create a changeset, but I cannot update it: # katello -u alice -p alice changeset update --add_template test1 --org \ ACME_Corporation --name cs3 --environment dev User alice is not allowed to access api/templates/index This is fixed by adding system_templates read_all permissions: katello -u admin -p admin permission create --user_role Changeset_manager --name SysTem_read --scope system_templates --verbs read_all Now, the changeset cannot be promoted: # katello -u alice -p alice changeset promote --org ACME_Corporation --name cs3\ --environment dev Promoting the changeset, please wait... User alice is not allowed to access api/tasks/show It shows state: Promoting So this should be fixed when these commits are applied.. d1cff2ad36bb0431cd5a3ba036dcf0e089d47898 b12aff39ca12d0c70538f3ac5a912a187f28005f af2280b1ac97274aef71dd6fc90dbf3f5351d492 14f3126afc054088425c34852accf2d5dd9e7478 1079ea475636e7a17e798ca69e536a2669525027 look at https://github.com/Katello/katello/pull/116 for discussions In short the condition for environment perms was some what relaxed to say, if you can do any of the sub operations of an environment you should be at the least able to read its name/id/prior information. This should fix the above issues. The First example could pass only with the below permissions. Permissions: modify providerts_admin products for: providers verbs: update on: [root@dhcp201-200 ~]# katello -u alice -p alice changeset create --org redhat --name cs3 --environment Dev Successfully created changeset [ cs3 ] for environment [ Dev ] [root@dhcp201-200 ~]# katello -u alice -p alice changeset create --org redhat --name cs31 --environment Dev Successfully created changeset [ cs31 ] for environment [ Dev ] [root@dhcp201-200 ~]# katello -u alice -p alice changeset create --org redhat --name cs33 --environment Dev Successfully created changeset [ cs33 ] for environment [ Dev ] [root@dhcp201-200 ~]# katello -u alice -p alice changeset update --name "cs33" --add_product "rhel63" --org redhat --environment Dev Successfully updated changeset [ cs33 ] [root@dhcp201-200 ~]# katello -u alice -p alice changeset promote --name "cs33" --org redhat --environment Dev Changeset [ cs33 ] applied [root@dhcp201-200 ~]# katello -u admin -p admin user list_roles --username alice --------------------------------------------------------------------------------------------------------------------------------- User Role List Id Name --------------------------------------------------------------------------------------------------------------------------------- 14 Changeset_manager [root@dhcp201-200 ~]# katello -u admin -p admin user_role info --name Changeset_manager --permission_details --------------------------------------------------------------------------------------------------------------------------------- User Role Information --------------------------------------------------------------------------------------------------------------------------------- Id: 14 Name: Changeset_manager Description: None Permissions: modify providerts_admin products for: providers verbs: update on: read_sys_temp for: system_templates verbs: read_all on: Manage_changesets for: environments verbs: manage_changesets, promote_changesets, read_changesets on: Ldap Groups: 2) Also please confirm whether the promotion only after providing the above permissions and roles is correct? 3) Can someone please summarize as to what was decided or what needs to be verified for second example. Or is even second example verification required? For comment #9, I think it would be valuable to document the permissions required for several scenarios because it is not obvious nor intuitive. The promotion now works given the permissions above. If documentation of this is required for the User Guide, please create another bugzilla and assign it to documentation so it can be added to the list of required content. Thank you, Athene 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. http://rhn.redhat.com/errata/RHSA-2012-1543.html |