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