News:

SMF 2.1.4 has been released! Take it for a spin! Read more.

Main Menu

"Administrate forum and database" permission split up

Started by devil9394, April 10, 2012, 01:29:44 PM

Previous topic - Next topic

devil9394

I wanted to suggest something related to the Permissions.

"Administrate forum and database" permission should be split up in some other options, since there are some important things that could be added to some ranks, without giving the access of the most important and secret things of the forum (Package Manager, to all the Configuration Permissions)

- Censored List (from Posts and Topics): This list could be edited by other ranks, without having access to the Package Manager, to all the Configuration Permissions, etc.

And I don't know, if you think some more things from there could be split up, it'd be very good.

NanoSector

Yeah, I have to agree.

By checking that box you are giving the membergroup too many permissions.
I think it should be split up in MANY other sub-permissions. Too many to list right now, really.
My Mods / Mod Builder - A tool to easily create mods / Blog
"I've heard from a reliable source that the Answer is 42. But, still no word on what the question is."

devil9394

Quote from: Yoshi2889 on April 10, 2012, 02:56:23 PM
Yeah, I have to agree.

By checking that box you are giving the membergroup too many permissions.
I think it should be split up in MANY other sub-permissions. Too many to list right now, really.
Exactly what I meant.
Thank you for your opinion. ;)

emanuele

Quote from: Yoshi2889 on April 10, 2012, 02:56:23 PM
Too many to list right now, really.
But without a list we cannot know what you have in mind... ;D


Take a peek at what I'm doing! ;D




Hai bisogno di supporto in Italiano?

Aiutateci ad aiutarvi: spiegate bene il vostro problema: no, "non funziona" non è una spiegazione!!
1) Cosa fai,
2) cosa ti aspetti,
3) cosa ottieni.

NanoSector

Quote from: emanuele on April 12, 2012, 07:42:19 AM
Quote from: Yoshi2889 on April 10, 2012, 02:56:23 PM
Too many to list right now, really.
But without a list we cannot know what you have in mind... ;D
1. Install packages.
2. Install languages.
3. Modify server settings.
4. Enable/disable core features.
5. Open the Error Log.
6. Open the Administration log.
7. Open the Moderation log.
8. Run maintenance tasks.

And I can go on for like 100 more entries right now.
My Mods / Mod Builder - A tool to easily create mods / Blog
"I've heard from a reliable source that the Answer is 42. But, still no word on what the question is."

emanuele

So basically you would like a single permission for every single menu entry?


Take a peek at what I'm doing! ;D




Hai bisogno di supporto in Italiano?

Aiutateci ad aiutarvi: spiegate bene il vostro problema: no, "non funziona" non è una spiegazione!!
1) Cosa fai,
2) cosa ti aspetti,
3) cosa ottieni.

NanoSector

Quote from: emanuele on April 12, 2012, 07:55:14 AM
So basically you would like a single permission for every single menu entry?
No, for anything an admin can do. Not for every menu entry.

Just allow people to tune the permissions in precision instead of a sluggy master permission.
My Mods / Mod Builder - A tool to easily create mods / Blog
"I've heard from a reliable source that the Answer is 42. But, still no word on what the question is."

emanuele

Disclaimer: I'm not trying to say the proposal is not valid, I'm discussing how it could be useful. ;)

Okay, then I can start with the short list you posted:
Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM
1. Install packages.
2. Install languages.
3. Modify server settings.
If you allow someone to install a package he should be allowed to install a lang-pack and vice versa. In my opinion.
But to install packages then you may need to be able to modify server settings, or maybe you just need to know then (i.e. ftp password).
So I don't see any reason to separate them.

Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM
4. Enable/disable core features.
So you would give a person the ability to enable or disable core features just "for the fun of it"?
A core feature is something important that should be part of the forum or not based on the goal of the forum, not just something that (warning: exaggeration) a moderator should be able to turn off.
I think.
Additionally have the permission to install packages without the permission of enable core features is rather useless...

Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM
5. Open the Error Log.
In certain cases maybe this could help. Not sure how and why but it could I think.
Even though most likely any non-admin wouldn't be able to do anything in case of errors

Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM
6. Open the Administration log.
That's called "administration" because only admin should be able to see it.

Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM
7. Open the Moderation log.
?action=moderate;area=modlog
It's already a separated permission, you only find it in another location.

Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM
8. Run maintenance tasks.
Within the maintenance tasks thre is also the "database" set of tasks, giving someone the permission to access this gives him the permission to 1) convert the forum to utf8 (not exactly something that should be allowed to non-admins), 2) backup the database (i.e. gives the permission to collect all the email addresses and all the PMs of any member of the forum, again something a non-admin should not be able to do)
That said, I can agree that give separate permission to perform routine, members and topics maintenance tasks to another person without giving him any other permission could be useful.

So, from your list I'd save the permission to view error logs (should the list take care of hide IPs and/or personal informations?) and to run "basic" maintenance tasks.
Additionally I would add:
* a permission to manage current theme/layout (but that would be tricky because the non-admin member should not be able to change directories and urls IMHO);
* censored words could be linked to security and moderation and given a separated permission;
* calendar administration?...maybe...even though there isn't much to do.

That's what I can think about. All the other pages seem to me pretty much related or too "important" for a stand-alone permission...


Take a peek at what I'm doing! ;D




Hai bisogno di supporto in Italiano?

Aiutateci ad aiutarvi: spiegate bene il vostro problema: no, "non funziona" non è una spiegazione!!
1) Cosa fai,
2) cosa ti aspetti,
3) cosa ottieni.

NanoSector

I just chopped these right out of my head though.

Quote from: emanuele on April 12, 2012, 08:40:04 AM
Disclaimer: I'm not trying to say the proposal is not valid, I'm discussing how it could be useful. ;)

Okay, then I can start with the short list you posted:
Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM
1. Install packages.
2. Install languages.
3. Modify server settings.
If you allow someone to install a package he should be allowed to install a lang-pack and vice versa. In my opinion.
But to install packages then you may need to be able to modify server settings, or maybe you just need to know then (i.e. ftp password).
So I don't see any reason to separate them.
I think Server Settings should be separated anyway. Granting someone the permission to install packages doesn't mean they should be able to mess around with the server. They can ask the admin anyway if something fails to work.

Quote
Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM
4. Enable/disable core features.
So you would give a person the ability to enable or disable core features just "for the fun of it"?
A core feature is something important that should be part of the forum or not based on the goal of the forum, not just something that (warning: exaggeration) a moderator should be able to turn off.
I think.
Additionally have the permission to install packages without the permission of enable core features is rather useless...
Yes, though some sites have things as co-admins or even a separate group for site maintainer which should be granted permission to check that stuff.

Quote
Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM
5. Open the Error Log.
In certain cases maybe this could help. Not sure how and why but it could I think.
Even though most likely any non-admin wouldn't be able to do anything in case of errors
I think it'll help with checking the status of the site; not only admins should be allowed to do so.

Quote
Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM
6. Open the Administration log.
That's called "administration" because only admin should be able to see it.
Again coming with the point of co-admin and site maintainer.

Quote
Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM
7. Open the Moderation log.
?action=moderate;area=modlog
It's already a separated permission, you only find it in another location.
Meh, my bad ;D

Quote
Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM
8. Run maintenance tasks.
Within the maintenance tasks thre is also the "database" set of tasks, giving someone the permission to access this gives him the permission to 1) convert the forum to utf8 (not exactly something that should be allowed to non-admins), 2) backup the database (i.e. gives the permission to collect all the email addresses and all the PMs of any member of the forum, again something a non-admin should not be able to do)
That said, I can agree that give separate permission to perform routine, members and topics maintenance tasks to another person without giving him any other permission could be useful.
Yes, that's what I'm thinking. Maybe even create a sub-permission like "Manage the database" or something that allows you to do the database routine.

Quote
So, from your list I'd save the permission to view error logs (should the list take care of hide IPs and/or personal informations?) and to run "basic" maintenance tasks.
Additionally I would add:
* a permission to manage current theme/layout (but that would be tricky because the non-admin member should not be able to change directories and urls IMHO);
* censored words could be linked to security and moderation and given a separated permission;
* calendar administration?...maybe...even though there isn't much to do.

That's what I can think about. All the other pages seem to me pretty much related or too "important" for a stand-alone permission...
Guess I'll agree with that, though the first point doesn't need to be difficult; just do not allow access to the paths stuff.
My Mods / Mod Builder - A tool to easily create mods / Blog
"I've heard from a reliable source that the Answer is 42. But, still no word on what the question is."

Norv

Fully agree with Emanuele.

I don't really see the usefulness of error logs without IPs and in fact I can think of more; nor am I sure about (immediate, i.e. 2.1) need for calendar admin.

I'd add a couple of things here.
Quote from: Yoshi2889 on April 12, 2012, 07:59:54 AM
Quote from: emanuele on April 12, 2012, 07:55:14 AM
So basically you would like a single permission for every single menu entry?
No, for anything an admin can do. Not for every menu entry.

Just allow people to tune the permissions in precision instead of a sluggy master permission.

One "sluggy" master permission is there basically because just about any admin action like those either requires or implies others. They give one (or require one to have, to do the job right), *admin* permissions over the forum.

Quote
Quote
Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM
1. Install packages.
2. Install languages.
3. Modify server settings.
If you allow someone to install a package he should be allowed to install a lang-pack and vice versa. In my opinion.
But to install packages then you may need to be able to modify server settings, or maybe you just need to know then (i.e. ftp password).
So I don't see any reason to separate them.
I think Server Settings should be separated anyway. Granting someone the permission to install packages doesn't mean they should be able to mess around with the server. They can ask the admin anyway if something fails to work.

One of the problems here is, "something fails to work" in package installation may put the site offline. Until they can ask the admin.
Also, they can find out the server settings anyway, since they are able to install a package which does/reads anything on forum database/files. In other words, granting someone permission to install packages means they are perfectly able to mess around with the entire forum.


I don't know what means the concept of co-admin, if it's not an admin of at least "forum and database".
To-do lists are for deferral. The more things you write down the later they're done... until you have 100s of lists of things you don't do.

File a security report | Developers' Blog | Bug Tracker


Also known as Norv on D* | Norv N. on G+ | Norv on Github

NanoSector

Too lazy to quote right now, so:

1. The master permission can be separated well enough. A lot of actions do not need others to work.

2. You have a point there, though if you are admin of a site, you should at least have the main admin's e-mail. At least that's what I think.

3. My concept of co-admin is a separate membergroup that basically is just admin, like, not able to do EVERYTHING an admin is able to do.
My Mods / Mod Builder - A tool to easily create mods / Blog
"I've heard from a reliable source that the Answer is 42. But, still no word on what the question is."

IchBin™

I don't think any user should be able to touch the package manager without being Admin.
IchBin™        TinyPortal

Norv

Yoshi One, a little reminder: point 2/ has two sub-points. The second is exactly that they are able to do everything an admin is able to do, if only they install the right mod, or use the database, etc etc.

Ema may want to analyze the very particular cases where something may be done, but basically I think things should be this way: in the permissions redesign (which will happen for 3.0 or up), there's quite some mess in permissions to rethink. If you wish, it might be interesting to take others for a discussion.
However, something like the critical administration tasks, meaning these ones (basically), must remain together. With them, you made someone an admin anyway. (and it's not even relevant if they have other permissions, they could take them: they administrate.). That's an admin/co-admin: they are administrating forum/database.

It would be dangerous to split them in such way that people may think their "co-admin" has a permission like 'install packages/language files' and not 'server settings access'. Because it's basically false, and basically a false sense of security, on a critical bit: those 'co-admins' can access server settings. And just about everything else on the forum.
To-do lists are for deferral. The more things you write down the later they're done... until you have 100s of lists of things you don't do.

File a security report | Developers' Blog | Bug Tracker


Also known as Norv on D* | Norv N. on G+ | Norv on Github

emanuele

Quote from: N. N. on April 12, 2012, 02:46:30 PM
However, something like the critical administration tasks, meaning these ones (basically), must remain together. With them, you made someone an admin anyway. (and it's not even relevant if they have other permissions, they could take them: they administrate.). That's an admin/co-admin: they are administrating forum/database.

It would be dangerous to split them in such way that people may think their "co-admin" has a permission like 'install packages/language files' and not 'server settings access'. Because it's basically false, and basically a false sense of security, on a critical bit: those 'co-admins' can access server settings. And just about everything else on the forum.
While writing my previous post I was even considering to go a step further and propose to completely remove those "admin-only" permissions and reserve them for the admin group only.
Maybe too much...


Take a peek at what I'm doing! ;D




Hai bisogno di supporto in Italiano?

Aiutateci ad aiutarvi: spiegate bene il vostro problema: no, "non funziona" non è una spiegazione!!
1) Cosa fai,
2) cosa ti aspetti,
3) cosa ottieni.

NanoSector

While I must agree, I still think the current permission is too much in one package. It should definitely be split up in way more permissions. How and what you are going to split really doesn't matter much to me, but really, lots of stuff can be split from it.
My Mods / Mod Builder - A tool to easily create mods / Blog
"I've heard from a reliable source that the Answer is 42. But, still no word on what the question is."

Norv

Quote from: emanuele on April 12, 2012, 03:36:15 PM
Quote from: N. N. on April 12, 2012, 02:46:30 PM
However, something like the critical administration tasks, meaning these ones (basically), must remain together. With them, you made someone an admin anyway. (and it's not even relevant if they have other permissions, they could take them: they administrate.). That's an admin/co-admin: they are administrating forum/database.

It would be dangerous to split them in such way that people may think their "co-admin" has a permission like 'install packages/language files' and not 'server settings access'. Because it's basically false, and basically a false sense of security, on a critical bit: those 'co-admins' can access server settings. And just about everything else on the forum.
While writing my previous post I was even considering to go a step further and propose to completely remove those "admin-only" permissions and reserve them for the admin group only.
Maybe too much...

Yep. Crossed my mind. :D
To-do lists are for deferral. The more things you write down the later they're done... until you have 100s of lists of things you don't do.

File a security report | Developers' Blog | Bug Tracker


Also known as Norv on D* | Norv N. on G+ | Norv on Github

devil9394

I'd like to thank you all for your comments and ideas regarding this topic.

Quote from: Yoshi2889 on April 12, 2012, 03:51:31 PM
While I must agree, I still think the current permission is too much in one package. It should definitely be split up in way more permissions. How and what you are going to split really doesn't matter much to me, but really, lots of stuff can be split from it.
This is exactly what I meant, there are too many things integrated in only one permission, some of them being useful things that could be given to who knows what rank, without giving the access of the most important and secret things of the forum.
And if this split up would make problems to some amateur SMF users, then it could be added on a separate page, than the trivial Permissions page, so the amateur users won't give a too important permission to who knows what rank, if you understand what I mean.

Norv

Other examples than 'administrate forum and database' would be useful, devil9394, if you can propose some and their usefulness.
To-do lists are for deferral. The more things you write down the later they're done... until you have 100s of lists of things you don't do.

File a security report | Developers' Blog | Bug Tracker


Also known as Norv on D* | Norv N. on G+ | Norv on Github

devil9394

Manage Censored Words List (Posts and Topics -> Censored Words): This function could be added to some low ranks, without having to give them all the other things from "Administrate forum and database".

I'd suggest some other things that could be split up, but these things are more for those that I could, and would like to, add to some lower ranks without giving access to server settings, therefore there is no need for me to suggest them, as they wouldn't fit in all the cases.

青山 素子

Quote from: devil9394 on April 19, 2012, 11:01:10 AM
Manage Censored Words List (Posts and Topics -> Censored Words): This function could be added to some low ranks, without having to give them all the other things from "Administrate forum and database".

It's a good idea, but the only problem is that the replacement for the censored word can be any kind of thing at all, even JavaScript and arbitrary HTML. The feature would have to be re-written to not allow anything beyond basic bbcode to make it safe for granting to non-admins. Personally, I think it has merit.
Motoko-chan
Director, Simple Machines

Note: Unless otherwise stated, my posts are not representative of any official position or opinion of Simple Machines.


Advertisement: