Content subsystem and privileges

Lukas Krejci lkrejci at redhat.com
Wed Feb 2 17:15:14 UTC 2011


On Wednesday, February 02, 2011 18:04:35 Lukas Krejci wrote:
> Ok, as discussed with mazz and others, this really needs to be looked at
> more thoroughly.
> 
> So let me start off the discussion by a first attempt at defining the
> "proper" content privileges that would make sense for all content related
> functionality - the content subsystem itself, bundles as well as
> server-side scripts.
> 
> On Wednesday, February 02, 2011 15:23:36 Lukas Krejci wrote:
> 
> ... snip ...
> 
> > 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.
> 
> First of all, I think we need to completely cut the content privileges away
> from the inventory privileges.
> 
> 1) CRUD content sources - I think there are no "special" privileges needed
> for the content sources as they can be understood as sources (! ;) )
> providing the content to the repositories, which should be understood as
> the corner-stone of our content system. The importance has shifted from
> the content source to a repository when we added the ability to upload a
> package to the repo without there having to be a content source backing
> it. Therefore anyone able to at least update repositories, will have full
> CRUD on the content sources. I'd just make one explicit rule here:
> - a content source cannot be deleted when associated to a repo (which is
> possible today).
> 
> 2) CRUD repos
> - MANAGE_REPOSITORIES - global permission for an ultimate access to all
> repos - UPDATE_REPOSITORY - per-repo privilege to edit its metadata, its
> content sources, and packages
> - MANAGE_PACKAGES - per-repo privilege to CR packages and package versions
> in it (I don't think we can allow for deleting or updating packages in any
> other way than for them to "disappear" from the content source, i.e. I
> wouldn't allow users to delete/update packages unless we also implement
> some kind of audit trail for repositories which we currently don't have).
> - VIEW_REPOSITORY - per-repo readonly access to the repo itself and
> packages in it
> 
> 3) Associate content resource with repos - UPDATE_REPOSITORY
> 
> 4) Subscribe resources to repos - MANAGE_CONTENT on the resource +
> VIEW_REPOSITORY on the repo
> 
> 5) CRUD Bundles
> Bundles, even though they build upon content, are a standalone subsystem,
> so we need to mostly mirror the privileges defined for repos
> - MANAGE_BUNDLES - global permission for an ulitmate access to all bundles
> - UPDATE_BUNDLE - per-bundle privilege to edit its metadata and versions
> - VIEW_BUNDLE - per-bundle privilege to see the bundle
> 
> 6) Deploy bundles -
> either VIEW_BUNDLE on the bundle + MANAGE_CONTENT on the platform
> resources, or:
> - DEPLOY_BUNDLE - per-resource privilege to deploy the bundles to it
> 
> 7) CR(UD?) package versions in a repo
> - as mentioned above, MANAGE_PACKAGES on a repo.
> 
> 
> As an example for what privileges would a user need to upload a new script
> for CLI alert script:
> MANAGE_ALERTS on a resource and MANAGE_PACKAGES on one or more repos.
> 
> To create a CLI alert using one of the pre-existing scripts:
> MANAGE_ALERTS on a resource and VIEW_REPOSITORY on one or more repos.
> 
> A possible simplification would be to drop the VIEW_REPOSITORY and
> VIEW_BUNDLE privileges and imply them for everyone as it is currently done
> for bundles.
> 
> Another question we need to answer here is that of the amount of additional
> work we'd add on the shoulders of the RHQ admin by implementing these.
> How many repositories are there going to be that the admin will have to
> setup the privs for?
> How many bundles?
> And what should the per-bundle/per-repo privs default to when a new
> bundle/repo gets added (precisely, this means: when a new bundle/repo gets
> added, then what privileges should it be automatically assigned for each
> role?)?

Ok, wrong.. :) To follow the logic we have for resource groups the question 
must stand:

What roles should the newly-added repo/bundle be assigned to?

> Would the users benefit from "bundle groups"?
> 
> What are your thoughts?
> 
> Lukas
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list