Bug 536507 (RHQ-84) - Content Security System
Summary: Content Security System
Keywords:
Status: CLOSED DEFERRED
Alias: RHQ-84
Product: RHQ Project
Classification: Other
Component: Core Server
Version: 1.0.1
Hardware: All
OS: All
high
medium
Target Milestone: ---
: ---
Assignee: RHQ Project Maintainer
QA Contact: Mike Foley
URL: http://jira.rhq-project.org/browse/RH...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-03-13 15:02 UTC by John Mazzitelli
Modified: 2014-05-15 21:13 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-05-15 21:13:34 UTC
Embargoed:


Attachments (Terms of Use)

Description John Mazzitelli 2008-03-13 15:02:00 UTC
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 15:11:53 UTC
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 15:41:18 UTC
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 18:22:46 UTC
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 18:30:07 UTC
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 18:37:13 UTC
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 17:41:26 UTC
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 17:42:30 UTC
Setting to critical so it gets triaged

Comment 8 Charles Crouch 2008-03-14 17:50:14 UTC
Assigning to greg for more opinions

Comment 9 Greg Hinkle 2008-05-22 14:32:30 UTC
Either way, this is a significant enhancement request and won't fit in 1.0.1.

Comment 10 Red Hat Bugzilla 2009-11-10 21:18:12 UTC
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 21:13:34 UTC
Deferring to redesign of content.


Note You need to log in before you can comment on or make changes to this bug.