|
|
| (2 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| This proposal is pretty good, in that it is simple, and will work. I just worry that it is just tring to preseve the existing 7 roles:
| |
|
| |
|
| ;minimal
| |
| :guest
| |
| ;standard
| |
| :student, non-editing teacher
| |
| ;high
| |
| :editing teacher, course creator
| |
| ;absolute
| |
| :admin, oringinal admin
| |
|
| |
|
| Of course our current security model is build round these concepts, so changing it is a risk. Also, it is clearly not future proof to have 4 hard-coded levels.
| | I think that RISK_SPAM is a good name. The one I don't like is RISK_ADMIN. Admin is not a risk, it is a historical role that had this level of trust. The best alternative I can think of is RISK_CONFIG - user can change global configuration, which opens potentially unimited security risks.[[User:Tim Hunt|Tim Hunt]] 17:46, 18 September 2006 (CDT) |
| | |
| As I understand it: the new roles system is secure with the default settings, and it remains secure if the roles and permissions settings at a site are only editing by people who fully understand all the consequences of their actions. It is just the the new system is so powerful that it makes it too easy for people to screw up. Therefore, we need to protect them from themselves. Do I understand the problem correctly?
| |
| | |
| However, the new roles system is meant to make things more flexible, and at a large installation you might want to trust some people with some of the things you classify as high rist, but not others. For example, you might want to trust them to edit or upload uncleaned content, but not to handle backups nor create courses. Under your model, you would have to give these people high trust level, and then it would be possible give them capabilities that we would rather they did not have by mistake.
| |
| | |
| So can I suggest a slightly more flexible (and hence slightly more complicated solution). Instead of trust levels, have risks. For example:
| |
| * Access to sensitive information
| |
| * Add uncleaned content
| |
| * Destroy the site
| |
| Then for each user, list which risks you trust them not to exploit maliciously. For each cabability, list which risks it opens up.
| |
| | |
| All the checks you want to perform are still possible under my system. Explaining it is still easy, if not easier, because you can explain the possible consequences of trusting someone one risk at a time. Basically, instead of using integer trust levels and >= operator, we are using sets of risks and the superset operator. Very similar to implement, but much more flexible when we discover new classes of risk in the future.
| |
| | |
| --[[User:Tim Hunt|Tim Hunt]] 15:51, 16 August 2006 (WST)
| |
I think that RISK_SPAM is a good name. The one I don't like is RISK_ADMIN. Admin is not a risk, it is a historical role that had this level of trust. The best alternative I can think of is RISK_CONFIG - user can change global configuration, which opens potentially unimited security risks.Tim Hunt 17:46, 18 September 2006 (CDT)
