Currently the content subsystem lacks any finer grained authorization model and most of the work simply requires MANAGE_INVENTORY permission. In the proposed Design - Serverside scripts, it has been found that this is insufficient if we want to allow users that don't have such a strong permission as MANAGE_INVENTORY to create alert notifications using a CLI script (that is being stored inside a repo).
The following is the proposal for enhancing the content subsystem with a little more fine-grained authorization options to improve on the current situation.
This new global permission will replace the MANAGE_INVENTORY in all the content related tasks (more specific rules being outlined further in the text). This is to conceptually separate these two different user roles. During upgrade of existing installations, all the roles that had MANAGE_INVENTORY permission will be automatically assigned MANAGE_REPOSITORY as well so that no unexpected disruptions occur.
To enable users without MANAGE_REPOSITORIES to work with packages (i.e. primarily to store the CLI scripts to be used on the server-side) the following changes will be made to the way repos are accessed:
Everybody in the system will be able to create a repo.
A repo can be owned (associated with a user).
A repo can be private.
If it is owned, it can be accessed by the owner and by users having MANAGE_REPOSITORIES
If it is not owned, it can only be accessed by users having MANAGE_REPOSITORIES
A repo can be public - regardless of who (if anyone) owns the repository, it can be viewed and packages read from it by anyone.
The owner can freely switch between public and private but once a public repo becomes private, the other users won't be able to access packages from it anymore. This means that for example existing CLI alerts will cease to function. This is potentially dangerous but has its reasons. Making the repo private means that it potentially contains "stuff" the user doesn't want to share with others (thing scripts containing some sensitive information like credentials, ip addresses, etc.) and letting others use a script from this repository even after it's been made public could mean that such sensitive information would "leak" into the hands of other users.
All the currently existing repos will have no owner and will be private after upgrade to maintain the original functionality.
Only users with MANAGE_REPOSITORIES will be able to associate content sources with repos.
In order to subscribe a resource to a repo, a user will have to these privs:
"see" the repo (i.e. the repo has to be public or the user must own it or the user must have MANAGE_REPOSITORIES)
have MANAGE_CONTENT perm on the resource
Previously only MANAGE_CONTENT was theoretically needed, but in order to see the available repos, the user had to have MANAGE_INVENTORY, which in effect forced the user to have MANAGE_INVENTORY to be able to subscribe
There will have to be some minor changes to the UI. Firstly, we'll need to add the checkbox to set the repo public or private, the MANAGE_REPOSITORIES privileged users will have to have the ability to reassign the owner of the repo. We'll have to add a button to upload data to a repo and buttons to delete a package version or a whole package. This would be best done if the UI was ported to GWT so that we could redesign the user interface to be slightly more usable and meaningful.