Content subsystem and privileges

Lukas Krejci lkrejci at redhat.com
Wed Feb 2 14:23:36 UTC 2011


Hi all,

this is to raise some questions about our usage of user/role privileges when 
working with the content subsystem.

First, let me try to dissect the content subsystem by use cases:

1) CRUD content sources
2) CRUD repos
3) Associate content sources with repos
4) Subscribe resources to repos
5) CRUD bundles (which CRUDs repos, packages and package versions under the 
hood)
------ the following is new with CLI alerts
6) CR(UD?) package versions in a repo (well, this is somewhat similar to what 
bundles require)

Now let's look at the privileges that those use cases currently require:

1) CRUD content sources - MANAGE_INVENTORY for everything
2) CRUD repos - MANAGE_INVENTORY
3) Associate content sources with repos - MANAGE_INVENTORY
4) Subscribe resources to repos - MANAGE_CONTENT on the individual resources
5) CRUD bundles - R is not privileged, MANAGE_BUNDLE (bundles, being a 
standalone subsystem, circumvent the otherwise needed MANAGE_INVENTORY for 
repo/package/package version CRUD)
6) CR(UD?) package versions in a repo - ?

In the light of 6), I find the above setup insufficient. We need any user 
capable of creating alerts be able to upload a script (i.e. create a package) 
in some repo but we just don't have privileges that would guard what repos he 
can see/upload to. Of course, we can circumvent this and just say "everyone 
can upload stuff to the configured repo" but I don't know if I like it.

Also, it should be possible for the alert definition creator to select a pre-
existing script from some repo. Again, we either circumvent the privileges 
altogether and just allow him to "see" all the repos and packages inside it 
(i.e. implied read for anyone as we do with bundles) or define some more fine-
grained privilege system around this. 

I don't think we can get away with MANAGE_INVENTORY for just about everything 
anymore.

We could define a new global UPLOAD_CONTENT privilege (akin to MANAGE_BUNDLE) 
and play games with it in the numerous content-related managers but I don't 
find this ideal.

With the introduction of CLI alert scripts (and to a great extent with bundles 
as well) we basically broke the original design assumptions of the content 
subsystem that was tightly coupled to the resource types / resources and thus 
could get away with the global MANAGE_INVENTORY for setting up the content 
source/repo infrastructure and resource specific MANAGE_CONTENT for hooking up 
the resources with the repos and work with packages (btw. to list the 
available repos, one needs MANAGE_INVENTORY but to subscribe, one only needs 
MANAGE_CONTENT, but since one's never able to actually see what to subscribe 
to without MANAGE_INVENTORY, I find the MANAGE_CONTENT requirement kinda weird 
here).

Bundles, being a subsystem on their own, worked around this lack of fine-
grained privileges by introducing a new privilege for themselves. A user 
having MANAGE_BUNDLE can do anything with bundles and deploy to all platforms.

CLI alerts on the other hand don't define their own subsystem and try to use 
only the existing content subsystem. The design (http://wiki.rhq-
project.org/display/RHQ/Design+-+Serverside+scripts) works quite nicely with 
just a single change to the content subsystem but by using it the way it was 
not originally designed for, we are going to "feel" the lack of the privilege 
types here.

I'd like to introduce repo level privileges (which would be implied by 
MANAGE_INVENTORY not to break the backwards compatibility):

VIEW_REPO - per-repo privilege for each role, MANAGE_INVENTORY implies this. 
This privilege would give the user the ability to see the repository and the 
packages and package versions inside it (to see the resources associated with 
those package versions, one would need MANAGE_INVENTORY as it is now). Maybe 
MANAGE_CONTENT on a resource could imply VIEW_REPO on all repositories to work 
around the problem outlined above.

UPLOAD_CONTENT - again, per-repo privilege for each role, implies VIEW_REPO, 
implied by MANAGE_INVENTORY, allows the user to upload new package versions to 
the repository.

Obviously this is going to require quite a couple of changes in the UI and in 
the business logic but would enable the admins to assign proper visibility of 
the repos.

So, to summarize, I propose to change the privileges to something like this:

1) CRUD content sources - MANAGE_INVENTORY for everything
2) CRUD repos - VIEW_REPO for R, MANAGE_INVENTORY for CUD
3) Associate content sources with repos - MANAGE_INVENTORY
4) Subscribe resources to repos - MANAGE_CONTENT on the individual resources 
(having VIEW_REPO, even without MANAGE_CONTENT implying it, would help the 
MANAGE_INVENTORY vs. MANAGE_CONTENT conflict mentioned above)
5) CRUD bundles -  R is not privileged, MANAGE_BUNDLE for CUD 
6) CR(UD?) package versions in a repo - UPLOAD_CONTENT for C, VIEW_REPO for R

The changes outlined in http://wiki.rhq-project.org/display/RHQ/Design-
Content+Deployment make the MANAGE_CONTENT privilege obsolete and I think the 
proposed VIEW_REPO fits in the removal of the repo-resource association very 
well, too.

What are your thoughts?

Lukas


More information about the rhq-devel mailing list