Hi,
I’d like to propose a permissions level called “Developer”. It would give full access to the administrative backend of a Discourse site without giving any access to the categories and discussions that the user does not have permissions or trust to access. Perhaps the users and groups tabs would also be disabled for this access level? This would give additional data security and confidentiality to site owners when they invite technical developers to do various work on their site.
How can the developer diagnose issues with particular topics without being able to see them?
Those developers might need Admin access. A plug-in developer would not. However, for my proposal, they would still have access to any Categories their user status allows for. So they could receive access to just the Categories they need access to if certain topics are involved in the problem.
How does a a plugin developer do their work on a production instance? Don’t they usually have development and sandbox instances for that?
The main point is there are use cases where a technical contractor needs Admin access. But, that doesn’t mean they need to be able to view all Cateogries on a site.
Perhaps they are installing and maintaining a plugin. Or installing/modifying CSS.
I think if you want to move this forward, you’re going to have to be a lot more specific in what you’re after. Detail exactly what such an access level would and wouldn’t be able to see, do, and so on. Preferably, a description of an actual use case “where a technical contractor needs Admin access”, but doesn’t need access to anything which would allow them to elevate their own privileges to obtain access to things you don’t want them to. As long as you talk in hypotheticals and unsupported assertions, I doubt you’ll get much traction.
The key point here is the need to prevent privilege escalation – if you’re in an adversarial situation where you have to give someone access to “certain things”, but can’t trust them not to look at things they’re not supposed to, then you presumably also can’t trust them not to use any access they are granted to go do shenanigans.
In particular, doing anything with plugins is a gateway to everything, because plugins not only have full access to the database and the entire codebase, but to install a plugin you need root on the box, which gives you direct access to everything as well.
Personally, I think you’d be better off not hiring people who you can’t trust, but hey, it’s your biscuit.
I can agree that not everyone is both Admin and developer. One could argue that various features would be better not available to one or the other.
I’m thinking that other than initial system setup and occasional support a developer does not need access to Admin pages on a live site. Similarly, a non-techy Admin should probably avoid guessing with the Admin Developer settings, and entering Badge queries if they’re enabled.
It could also be argued that a designer should have access to various style settings.
IMHO after initial setup it is communication, not limited access, that would be the better way to make changes. There is nothing wrong with a developer helping an Admin understand what a setting does, a designer giving style advice, or an Admin asking for help.
Hi Matt, I appreciate the candid feedback on the idea. Thank you.
How about this use case? A Discourse customer wants to do a rebranding of their community and hires Contractor to do the work. Contractor has a great reputation, brilliant work, etc. It seems reasonable to trust the Contractor to have admin status on the Discourse site. The Contractor also hires subcontractors to assist with the work of adding graphic files, changing CSS, etc. Now the Discourse customer has given full, unlimited access to their Discourse installation to three people, simply to rebrand their community site.
That’s a huge risk. If any one of those three people has a hidden reason to take advantage of the trust they have, this could be a disaster. Leaked financial documents, legal documents, private messages, strategic conversations, merger plans, etc. You probably know better than I do the near-daily headlines of hacks, leaks, sabotage, etc. across the software industry.
I think from an enterprise perspective, managing security risks is at the forefront of the C-suite. Here’s the internal organization conversation:
So what’s the best response to that question?
Limiting access won’t help – you need to fully trust anyone who is able to inject JavaScript into Discourse as they could trivially steal other user’s authentication tokens anyway.
The proper way to fix this is having development happen in a staging instance without sensitive or important data in it. When development is finished, review the results and apply them to your production instance 
In case you’re curious, Discourse themes can be easily exported and imported, so customization at that level should be easy to review independently and transfer from the staging instance to the production instance.
Preventive privilege escalation is probably impossible, but there’s still value in preventing “ambient” information disclosure.
It’s the difference between seeing “Evil Lair Plans” on the home page and doing database queries or code injection. Sure an attacker can do the latter, but it’s a lot more work and shows clear intent from someone who presumably is already trusted.