BOINC user rights
From Pirates@Home
BOINC has a fairly primitive system for giving certain users elevated privleges or for special identification, using a "special_user" bitmask. A user who has the 'moderator' bit set, for example, can perform a number of special tasks in the discussion forums which are not available to most users. I have been checking the 'administrator' bit for special purpose functions in the 'ops' area (the project control panel), but this is not yet a part of BOINC.
I would like to see a more robust authorization system which uses "roles based authorization", and I find the implementation used by MediaWiki worth emulating. In this system users may be made members of one or more permissions groups, and then the permissions assigned to the groups may be easily reconfigured to meet the requirements of the project. This is described in some detail on the MediaWiki "meta" site under Help:User rights.
One thing that is necessary for this to work for BOINC is to identify all the separate tasks for which special permissions might be needed. I am therefore beginning the list below. Most of these powers are currently assigned to "moderators" or "administrators" on BOINC projects. A separate list identifies desirable new permissions. In some cases these powers already exist for project administrators via the control panel. In other cases they are functions which may only be performed by manual manipulation of the database.
Contents |
I2U2 Requirements
I am interested in this in part because I would like to use it also on our I2U2 site, where I could grant teachers or student assistants some powers that do not exist on a regular BOINC site. A more configurable system would make that easily done, but also be useful for BOINC.
Existing Permissions
Some of these are permissions given to moderators, others are now currently given to all users, but could be restricted based on group membership. Each permission implicitly includes the permission to reverse the setting, but it's not clear yet if that is the correct way to implement this.
- rate_post
- rate a forum posting (plus or minus)
- rate_profile
- rate another user's profile
- subscribe
- subscribe to a thread to receive an e-mail notification whenever someone else posts to that thread
- delete_post
- delete a single posting. (It's not actually removed from the database, it's just not shown to the users.)
- move_post
- move a single posting to another thread
- move_thread
- move an entire thread to a different forum (room)
- edit_title
- edit the title of a thread
- sticky
- make a thread sticky, which makes it show up at the top of the list of threads, regardless of what the user has chosen for sort order. (also unsticky, or is that separate?)
- lock_thread
- lock or unlock a discussion thread (Or should unlock be a separate permission?)
Proposed Additions
- delete_thread
- delete an entire discussion thread (it's not actually deleted, it's just not shown to the users)
- suspend_user
- suspend a user's privelege of posting to the discussion forums or adding to the wiki
- create_forum
- create a new discussion forum (room)
- delete_forum
- delete a discussion room. It's not actually deleted, it's just put "in the attic", so that it doesn't show up in any listing, and only members of the room can view it (or everybody? that could be configurable)
- create_account
- Create a user account (or a batch of them?)
- RSS_news_admin
- create, edit and delete RSS news items
- manage_app_versions
- add, deprecate, modify or delete application versions
- hide_attachment
- hide an attachment for a particular forum posting (do we needs separate permissions for doing this generally, or doing this for a room you "own"?)
Granting Permissions
Another important part of a roles-based system is being able to easily grant permissions to someone else. This could be done in two ways. One is to change the person's group membership. The other is to grant specific permissions.
The ability to change someone's group membership arbitrarily could lead to security problems. That should be reserved for only a select few administrators. But we'd like to be able to delegate authority to change a user's membership in a particular group. Therefore I would suggest something like
- grant_group_xxxxx
- add or remove a user from permission group xxxxx
One could also be allowed to grant (or revoke) specific permissions, such as
- grant_hide_attachment
- grant another user the permission hide_attachment (or revoke that permission).
In any case, you should only be able to grant or revoke a permission which you already posess (is that right?)
