# Admin Restrictions?
**URL:** https://meta.discourse.org/t/admin-restrictions/43708
**Category:** Feature
**Created:** [May 5, 2016, 6:18am UTC](https://meta.discourse.org/t/admin-restrictions/43708 "2016-05-05T06:18:52Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@Overmind](https://meta.discourse.org/u/Overmind)
#### Post date: [May 5, 2016, 6:18am UTC](https://meta.discourse.org/t/admin-restrictions/43708/1 "2016-05-05T06:18:53Z")
Anyway to restrict admin privileges rather than giving them access to everything? For example in most other platforms you can add a user to the admin panel solely for the design permissions without having to give them access to every feature or allow people administrator access for the vast majority of features but prevent a complete forum backup from being downloaded or created, major system settings from being changed, etc.
At the very least on Discourse official hosted installations I’d highly prefer the “Account Management” section not be open to every administrator as it contains payment information and the ability to modify subscription settings for the hosting.
I know it’s been mentioned in similar topics before **_“don’t make someone an admin/mod if you don’t trust them”_** – in some communities it’s harder than others to do that. For example ones run by volunteers compared to paid staff. However that argument isn’t the main point, **_if someone’s account is compromised_** (Could be anything from their email address being social engineered, their password being captured by malicious software, they reuse a password from another breached site, etc) which isn’t all that difficult without multi-factor authentication in place, then they’d have a whole lot of access.
In designing the security architecture we go by the popular principle of least privilege being the safest way to operate and to always assume a breach is possible so do your best to mitigate the fallout as well, not just look only at preventing the breach from happening. That way you’re more prepared. So by that principle you want users to have access only to the abilities they need to perform their job. (You don’t need a retail clerk to be able to download software to the POS system, they should only have access to the actions necessary for their job)
Once the forum settings have been decided, they rarely need to be changed/updated, so it’s not a privilege most administrators would need on a regular basis, once a design is implemented and tested it’s unlikely to change often so not a setting either that people would need often, payment details (especially last four digits and expiration date which are sensitive records, and enough to social engineer accounts with) are also not something every administrator would need access to. Could go on and on I’m sure.
An example of what we’d do in Xenforo would be have a super administrator account, set the privileges to each admin suited to their roles, even for the main ones that normally would have full access, if it’s not being updated we disabled access for any administrator to it, including myself. Then disabled the super admin access (it is something you had to update in the config.php on the server) so it could not be changed via the admin panel. That way, even in the event of a an admin’s account being breached, it wouldn’t have huge repercussions as they wouldn’t get full access to everything. They’d need to compromise the server as well to make themselves a super admin, and at that point they’d have access to the database anyway so it’s the worst case scenario there.
On Discourse though if any administrator is compromised (at least how I understand it, haven’t added an administrator since I last used it a year ago, current one still waiting on migration) then they’d be able to do a full backup of the forum, install a test version of Discourse, and compromise all the users. Disable SSL, change the CSS/templates to capture login information of members. Cancel subscription, disable the site.
Granted, keeping recent backups would mitigate data loss, but having administrator restrictions in place would help limit the scope of the damage greatly. These aren’t all hypothetical situations, it’s based breaches that have occurred on many forums in the past, both big and small.
---
### Author:  [@tobiaseigen](https://meta.discourse.org/u/tobiaseigen)
#### Post date: [May 5, 2016, 5:43pm UTC](https://meta.discourse.org/t/admin-restrictions/43708/2 "2016-05-05T17:43:01Z")
That’s super interesting - I self-host discourse so haven’t seen the hosted admin options which look different.
It does seem to me that out of the box roles might be required at some point if the admin is also going to be in charge of billing - this is definitely not the same person in my organization.
I suspect this is not going to be high priority for the discourse team, so likely plugin territory.
Do a search for ACL or roles based permissions and you’ll see there’s some ongoing conversations already about this.
---
### Author:  [@Overmind](https://meta.discourse.org/u/Overmind)
#### Post date: [May 5, 2016, 6:42pm UTC](https://meta.discourse.org/t/admin-restrictions/43708/3 "2016-05-05T18:42:52Z")
> [@tobiaseigen](#):
>
> hosted admin options which look different
Slightly, it’s just some small additions related to options specific to the hosting.
However, there is certainly a need for role based permission sets, it’ll become more apparent later on as Discourse grows, but the sooner it’s implemented the better.
For now I at least would like to have that payment information further redacted from the admin panel, it’s pretty revealing and that’s something that should only be shown to the company and the specific person paying the bill, not every single administrator, especially when most forums have volunteer admins.
Without role based permission sets it’s a vulnerability and target for any forum. If someone compromises _ANY_ administrator they compromise the _ENTIRE_ site. Just by getting a single password or stealing an email address, both are relatively trivial tasks for most forums, and there are little to no layers of added security in Discourse that could prevent that.
Right now the closest secondary security layer is an IP whitelist for the admin panel, which causes more issues than solves problems as many people don’t have static IP’s and would like to be able to manage it from multiple locations in case of emergency. I’ve certainly had times where I’ve had to use the admin panel on my phone, which the IP will change regularly except when I use a specific VPN, which most forums won’t have a company VPN to handle that.
Multi-factor authentication would limit the risk to a great extent as it would prevent the vast majority of account compromises, but it’s still highly preferred to solve the real problem by limiting access to important aspects of the site to those that will directly, regularly interact with those settings. Many settings won’t even be changed for months if at all after the initial setup, so it’s something that should be able to be locked down.
---
### Author:  [@yadlabus](https://meta.discourse.org/u/yadlabus)
#### Post date: [May 5, 2016, 7:00pm UTC](https://meta.discourse.org/t/admin-restrictions/43708/4 "2016-05-05T19:00:41Z")
> [@Overmind](#):
>
> However, there is certainly a need for role based permission sets, it’ll become more apparent later on as Discourse grows, but the sooner it’s implemented the better.
The case explained in [this topic](https://meta.discourse.org/t/ldap-sensible-data-hidden-to-admins/43749/1) would be another good example.
Especially in company-related forums, we must make a difference between the admin who sets up the platform, with low-level access to company strategic data, and the staff who will _administer_ the community on a regular basis, following the evolution of the forum and adapting its interface and configuration in consequence.
---
### Author:  [@jomaxro](https://meta.discourse.org/u/jomaxro)
#### Post date: [May 5, 2016, 7:04pm UTC](https://meta.discourse.org/t/admin-restrictions/43708/5 "2016-05-05T19:04:16Z")
This discussion has come up numerous times before (only found 2 topics, but it has definitely been discussed more).
> [@Modifying Staff Roles to go beyond Administrator and Moderator?](https://meta.discourse.org/t/modifying-staff-roles-to-go-beyond-administrator-and-moderator/36603):
>
> Hello all, We just got discourse for our new website and were wondering if there was a way to create other staff positions with different permissions besides Administrator and Moderator. i.e: Super Moderator; Super Administrator; etc. If not then whatever, not the end of the world, but it would be nice considering the original plan for the forum that we were going to implement.
> [@Allow moderators to add a member to a group?](https://meta.discourse.org/t/allow-moderators-to-add-a-member-to-a-group/16572/10):
>
> I know it’s been said multiple times that you guys want to avoid an overly complex role-based permission structure and that’s laudable, but by removing the concept of a global moderator, you’re just making more work for the forum admin. Ideally you have few admins (maybe one or two) and scale up moderators as needed, but in a large forum that has lots of groups, the small number of admins still have to manually assign users to groups—something that arguably isn’t an administrator task. I should…
My opinion on this is mixed. On the one hand, I like that Discourse is trying to avoid an overly complicated permissions system, that only one person (whoever created it) actually understands. On the other, 2 roles doesn’t seem to be enough for the growing variety of Discourse sites out there. Category Specific moderators are coming, but that role has less power than the current moderator and doesn’t address the issues brought up here. What seems to be needed is a “site-owner” type role. Moderators keep the current permission set, Admins lose access to sensitive site settings, the ability to download the entire site, and maybe a few other things I can’t think of, and Site-owners have full permissions (current Admin set).
---
### Author:  [@Overmind](https://meta.discourse.org/u/Overmind)
#### Post date: [May 5, 2016, 7:16pm UTC](https://meta.discourse.org/t/admin-restrictions/43708/6 "2016-05-05T19:16:45Z")
> [@jomaxro](#):
>
> My opinion on this is mixed. On the one hand, I like that Discourse is trying to avoid an overly complicated permissions system, that only one person (whoever created it) actually understands. On the other, 2 roles doesn’t seem to be enough for the growing variety of Discourse sites out there. Category Specific moderators are coming, but that role has less power than the current moderator and doesn’t address the issues brought up here. What seems to be needed is a “site-owner” type role. Moderators keep the current permission set, Admins lose access to sensitive site settings, the ability to download the entire site, and maybe a few other things I can’t think of, and Site-owners have full permissions (current Admin set).
Really this could be solved by only adding two new roles:
**1. SysAdmin/Site Owner** - Gets access to the settings/configurations, download backups, sensitive aspects that only the person(s) managing the server-side should see/modify. Normal admins wouldn’t have access to all of these settings, nor would these settings (other than backups) need to be regularly accessed, if it’s something that isn’t changing at least weekly or monthly, then it would be for this role.
**2. Designer** - Gets access only to the site customization tab, nothing else from the administrative aspect.
Those would cover just about every use case until people get to extremely specific and custom setups.
---
### Author:  [@jomaxro](https://meta.discourse.org/u/jomaxro)
#### Post date: [May 5, 2016, 7:30pm UTC](https://meta.discourse.org/t/admin-restrictions/43708/7 "2016-05-05T19:30:30Z")
> [@Overmind](#):
>
> **SysAdmin/Site Owner** - Gets access to the settings/configurations
Curious here. Are you proposing that an Admin (in your system) would have no access to **any** site setting (just remove the tab from their dashboard), or removal of access to sensitive site settings?
---
### Author:  [@tobiaseigen](https://meta.discourse.org/u/tobiaseigen)
#### Post date: [May 5, 2016, 7:34pm UTC](https://meta.discourse.org/t/admin-restrictions/43708/8 "2016-05-05T19:34:13Z")
These look good to me at first glance - but ask 10 different admins and you’re going to get 10 different new roles that are needed. 😉
Just yesterday I found myself wishing for the ability to give an intern access to update the data of birth for 80 community members. I had to do it myself which is not a great use of my time.
As much as I hate it, the drupal roles and permissions system ([just looking at it makes my heart race](https://s-media-cache-ak0.pinimg.com/originals/a5/3b/81/a53b818aae3dc5e5ae882d2515bab956.gif)) might be something to look at. It lets admins be very granular in giving access to various functions to different people.
---
### Author:  [@Overmind](https://meta.discourse.org/u/Overmind)
#### Post date: [May 5, 2016, 7:37pm UTC](https://meta.discourse.org/t/admin-restrictions/43708/9 "2016-05-05T19:37:55Z")
> [@jomaxro](#):
>
> Curious here. Are you proposing that an Admin (in your system) would have no access to any site setting (just remove the tab from their dashboard), or removal of access to sensitive site settings?
Really the entire settings tab is something that should rarely ever change once it’s all be setup. So I wouldn’t see an issue with that. Especially since you’d have the ability to give SysAdmin/Site Owner roles to multiple individuals if needed.
That role could be the only one with the settings, email, API, backup, update, or plugin tabs. So they’re the only one that can bulk export user data or make sensitive changes to the system.
> [@tobiaseigen](#):
>
> These look good to me at first glance - but ask 10 different admins and you’re going to get 10 different new roles that are needed. 😉
>
> Just yesterday I found myself wishing for the ability to give an intern access to update the data of birth for 80 community members. I had to do it myself which is not a great use of my time.
>
> As much as I hate it, the drupal roles and permissions system (just looking at it makes my heart race) might be something to look at. It lets admins be very granular in giving access to various functions to different people.
True, but this is in a way simplify it and keeping more sensitive data only used by those that need it. While I’d actually enjoy a complex, detailed role system – that would be a long way off, this is something practical, simplified in comparison and has very common, wide reaching use cases.
---
### Author:  [@jomaxro](https://meta.discourse.org/u/jomaxro)
#### Post date: [May 5, 2016, 7:42pm UTC](https://meta.discourse.org/t/admin-restrictions/43708/10 "2016-05-05T19:42:32Z")
> [@Overmind](#):
>
> Really the entire settings tab is something that should rarely ever change once it’s all be setup.
If you remove the entire setup tab (and email, API, backup, update, and plugin), what exactly is left for the Admin role? From what I can tell, that leave Group management, view all PMs, impersonate users, and a few post related actions (like change ownership). Writing that out, that sounds like a good bit of stuff they can do while protecting the site by decreasing who has access to API, backups, and critical site settings.
---
### Author:  [@tobiaseigen](https://meta.discourse.org/u/tobiaseigen)
#### Post date: [May 5, 2016, 7:48pm UTC](https://meta.discourse.org/t/admin-restrictions/43708/11 "2016-05-05T19:48:42Z")
It sounds to me like your own use case could be addressed by setting up a sandbox site and give your designer access to that. Then when you’ve got everything set up as you want it to be you copy the customizations to your live site. Probably a good way to operate in any case.
And as regards billing information - that really shouldn’t have been included in the discourse admin in my view.. the discourse team should have separated that out into a separate billing account center. I don’t want to be able to see my organization’s official credit card, and don’t particularly like the idea of it being backed up to S3 every day.
But then they probably have their own very good business reasons for doing it, probably to do with dogfooding and not wasting developer time building out another account center that they have to take care of apart from discourse. 🙂
So maybe there is a case to be made for the discourse team to add at least one more permission level for billing, which then opens the door to adding more, perhaps via community-contributed plugins?
Could be:
- super-admin = god privileges on the site
- admin = everything but backups, settings, sensitive data
- moderator = same as now
- billing = new billing tab? only on hosted discourse sites
- designer = access to customizations tab
---
### Author:  [@Overmind](https://meta.discourse.org/u/Overmind)
#### Post date: [May 5, 2016, 7:56pm UTC](https://meta.discourse.org/t/admin-restrictions/43708/12 "2016-05-05T19:56:32Z")
> [@tobiaseigen](#):
>
> It sounds to me like your own use case could be addressed by setting up a sandbox site and give your designer access to that. Then when you’ve got everything set up as you want it to be you copy the customizations to your live site. Probably a good way to operate in any case.
For the design aspect that’s what we intend to do (development board with non-sensitive data to use for testing).
> [@tobiaseigen](#):
>
> And as regards billing information - that really shouldn’t have been included in the discourse admin in my view.. the discourse team should have separated that out into a separate billing account center. I don’t want to be able to see my organization’s official credit card, and don’t particularly like the idea of it being backed up to S3 every day.
I completely agree. Or at least blank out the current card/payment data completely. I know which card I’m using, I see the bill and receipts, no one else needs to be able to see that data other than the individual paying and the company processing it.
> [@tobiaseigen](#):
>
> So maybe there is a case to be made for the discourse team to add at least one more permission level for billing, which then opens the door to adding more, perhaps via community-contributed plugins?
The billing would be strictly on their paid hosting plans, it’s only needed because they handle the display through the client’s admin panel.
> [@tobiaseigen](#):
>
> super-admin = god privileges on the site
> admin = everything but backups, settings, sensitive data
> moderator = same as now
> billing = new billing tab? only on hosted discourse sites
> designer = access to customizations tab
Agreed, design wouldn’t even be necessary as the development board solves that (can cost just a buck or two via AWS/Rackspace/Google/GoDaddy/etc when doing hourly billing to test design changes on a development build).
The billing wouldn’t be necessary either if they managed payments/subscriptions through [Discourse.org](http://Discourse.org) instead of the client’s board, or at least blanking out sensitive payment information completely. Currently it shows type of card, last 4 digits, expiration date, email. Too much information really.
---
### Author:  [@cpradio](https://meta.discourse.org/u/cpradio)
#### Post date: [May 5, 2016, 8:38pm UTC](https://meta.discourse.org/t/admin-restrictions/43708/13 "2016-05-05T20:38:32Z")
> [@tobiaseigen](#):
>
> Just yesterday I found myself wishing for the ability to give an intern access to update the data of birth for 80 community members. I had to do it myself which is not a great use of my time.
Can’t that be done with Moderator privileges? As a moderator I can alter the preferences of any user, does the date of birth show on the preference page?
---
### Author:  [@Overmind](https://meta.discourse.org/u/Overmind)
#### Post date: [May 5, 2016, 11:03pm UTC](https://meta.discourse.org/t/admin-restrictions/43708/14 "2016-05-05T23:03:33Z")
> [@cpradio](#):
>
> Can’t that be done with Moderator privileges? As a moderator I can alter the preferences of any user, does the date of birth show on the preference page?
Either none of the Discourse staff accounts on my hosted board have that field as an option or it’s something you have to do via the admin panel. Not sure since I don’t have a production discourse currently running (will once the import finishes 🙂 )
---
### Author:  [@cpradio](https://meta.discourse.org/u/cpradio)
#### Post date: [May 5, 2016, 11:27pm UTC](https://meta.discourse.org/t/admin-restrictions/43708/15 "2016-05-05T23:27:50Z")
I think date of birth is a custom user field. And if it is checked “Show on Profile”, it should be in the preferences (I think). But date of birth is definitely not a core field packaged in Discourse.
---
### Author:  [@dannie](https://meta.discourse.org/u/dannie)
#### Post date: [July 19, 2016, 7:19am UTC](https://meta.discourse.org/t/admin-restrictions/43708/16 "2016-07-19T07:19:03Z")
@codinghorror Is there a way we can limit some abilities to certain Admin?
For super admin, we can have a checklist to check or uncheck which power is granted to a specific admin. It can be a modal popup.
Example:
Admin 1 - Can do everything, except impersonate, see logs, API, or Backup.
Admin 2 - Can do all design changes only.
The list of power can be based here:
Dashboard, Settings, Users, Badges, Groups, Emails, Flags, Logs, Customize, API, Backups, Plugins, Impersonate
So if I set up one Admin and check only Customize. The only tab he/she will be seeing is the Customize tab on his admin panel.
I think this is a solution to all the Admin Restriction problems, temporarily. Because if they can’t see the tab, they won’t know that it’s possible for them to do it.
---
### Author:  [@Griff\_Wigley](https://meta.discourse.org/u/Griff_Wigley)
#### Post date: [April 2, 2018, 2:15pm UTC](https://meta.discourse.org/t/admin-restrictions/43708/17 "2018-04-02T14:15:52Z")
> [@tobiaseigen](#):
>
> super-admin = god privileges on the site
> admin = everything but backups, settings, sensitive data
I’ve got a new self-hosted site and would like the super-admin option. I know this discussion is pretty old but I’m wondering if anything was ever implemented. I’ve poked around and it seems not, but thought I’d check.
---
### Author:  [@jomaxro](https://meta.discourse.org/u/jomaxro)
#### Post date: [April 2, 2018, 3:29pm UTC](https://meta.discourse.org/t/admin-restrictions/43708/18 "2018-04-02T15:29:49Z")
Nope, never implemented. Admins have full ability to do anything on the site. The only restriction is impersonating other admin users.
---
### Author:  [@Dawn](https://meta.discourse.org/u/Dawn)
#### Post date: [June 10, 2021, 3:53pm UTC](https://meta.discourse.org/t/admin-restrictions/43708/19 "2021-06-10T15:53:49Z")
Has anything been developed to give different people different access rights? I’d rather not give our workforce management, business intelligence team, and department managers access to all of the settings available. They all could use some variation of the admin/moderator abilities.
---
### Author:  [@jomaxro](https://meta.discourse.org/u/jomaxro)
#### Post date: [June 10, 2021, 4:16pm UTC](https://meta.discourse.org/t/admin-restrictions/43708/20 "2021-06-10T16:16:53Z")
What specifically are you looking to give permission for?
Admins are still “all powerful” with moderators having a subset of those permissions. That said, many features have the ability to use groups. For example, the assign plugin can be used by groups if allowed by admins. [Data Explorer](https://meta.discourse.org/t/32566?silent=true) queries can be shared with groups. Groups can be given category moderation permissions. Users can be assigned as group owners. Etc.
[Next page](https://meta.discourse.org/t/admin-restrictions/43708.md?page=2)