|
History
| Log In
|
|
|
|
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.
Either way, this is a significant enhancement request and won't fit in 1.0.1.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Accepted
Critical
Content Security System
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