Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Content Security System|
|Product:||[Other] RHQ Project||Reporter:||John Mazzitelli <mazz>|
|Component:||Core Server||Assignee:||RHQ Project Maintainer <rhq-maint>|
|Status:||CLOSED DEFERRED||QA Contact:||Mike Foley <mfoley>|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-05-15 17:13:34 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description John Mazzitelli 2008-03-13 11:02:00 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.
Comment 1 John Mazzitelli 2008-03-13 11:11:53 EDT
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
Comment 2 Jeff Ortel 2008-03-13 11:41:18 EDT
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.
Comment 3 Greg Hinkle 2008-03-13 14:22:46 EDT
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)
Comment 4 Jason Dobies 2008-03-13 14:30:07 EDT
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.
Comment 5 John Mazzitelli 2008-03-13 14:37:13 EDT
so we need some other kind of perm... right now we have GLOBAL and RESOURCE perms. We need a CHANNEL perm? or CONTENT perm?
Comment 6 Charles Crouch 2008-03-14 13:41:26 EDT
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.
Comment 7 Charles Crouch 2008-03-14 13:42:30 EDT
Setting to critical so it gets triaged
Comment 8 Charles Crouch 2008-03-14 13:50:14 EDT
Assigning to greg for more opinions
Comment 9 Greg Hinkle 2008-05-22 10:32:30 EDT
Either way, this is a significant enhancement request and won't fit in 1.0.1.
Comment 10 Red Hat Bugzilla 2009-11-10 16:18:12 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-84 This bug is related to RHQ-78
Comment 11 Jay Shaughnessy 2014-05-15 17:13:34 EDT
Deferring to redesign of content.