Red Hat Bugzilla – Bug 536507
Content Security System
Last modified: 2014-05-15 17:13:34 EDT
We should look into either creating a new global permission for the content subsystem or adding fine-grained security for them. It would affect things like create channels, content sources, package versions, etc.
one instance where this comes to mind is the ContentManagerLocal.createPackageVersion. It is not associated with a resource request. But a UI object wants to call this when a user wants to upload content to be pushed to a resource (an EAR to a JbossAS instance for example). In this instance, I wonder if it would make sense to create a separate SLSB method for the UI to use and not expose this createPackageVersion We should attach this request to a specific resource... createPackageVersionForResource(Subject subject, int resourceId, ...the rest needed by createPackageVersion...) In here is where you would check to see if the user has the CONTENT resource perm on that resource then internally this createPackabgeVersionForResoruce would call createPackageVersion. That leaves createPackageVersion local and only remote that wrapper method
The ContentManagerLocal.createPackageVersion() has a user selected resource and uses this to determine which channels the new package version is to be associated with after it is created. Passing this resource to the createPackageVersion() so that the manager can do permission checking isn't quite right either. The resource the GUI is referencing is only associated with channels to which the package is added. So, we'd be doing a permission check on a very transient relationship for an operation that is likely to be more permanent. Meaning, the resource can get unsubscribed to the channel(s), but the package version will remain in the channel. Also, by adding the package to the channel, we're affecting more resources then just the one use to do the perm check. Seems like we'd have to do the perm check on all resources subscribed to all the channels we're adding the package to.
to be honest, i was expecting channels to get first-class fine-grained security. (i.e. direct control over who can do what to which channels)
I'm with Greg. We can't just scope creating packages for a particular resource, we should open it up as a channel operation, which would need its own permission scheme.
so we need some other kind of perm... right now we have GLOBAL and RESOURCE perms. We need a CHANNEL perm? or CONTENT perm?
This needs to be triaged for 1.0 inorder to ensure we are aware of any security implications. I dont think a whole new type of security is going to make it into 1.0. Maybe for right now we could restrict content src/channel mgmt to RHW admins, given these features are under the admin page.
Setting to critical so it gets triaged
Assigning to greg for more opinions
Either way, this is a significant enhancement request and won't fit in 1.0.1.
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-84 This bug is related to RHQ-78
Deferring to redesign of content.