How to prevent access of different user groups to different namespaces

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

How to prevent access of different user groups to different namespaces

Ken McDonald-2
 From what I've been reading, this seems possible, perhaps even without
special patches. However, there also seem to be a plethora of different
ways to go about this, and I'm wondering if the a "standard" way that is
recommended. I'm running MW 1.6.3, and can upgrade if necessary.

What I'd like to do is create a "Public" namespace. This will be
editable and mostly configurable to all logged in users. In addition,
users will be able to edit most "talk" pages, including that from the
main namespace.

Than Main namespace will be viewable by all (including *), but only
edited/changed by an "Editors" group.

A "Privileged" group may be created. If so, it will have all of the
abilities of the Editors group, plus the ability to view/edit a
"Private" namespace, which none of the lower-level groups can even read.
The basic intent is that new "official" pages will be developed here,
and then moved into the main namespace when complete.

Finally, "sysop" will be able to do anything.

Here's the stuff I've put into LocalConfiguration to try to get things
started:

/**
 * Additional namespaces. If the namespaces defined in Language.php and
 * Namespace.php are insufficient, you can create new ones here, for
example,
 * to import Help files in other languages.
 * PLEASE  NOTE: Once you delete a namespace, the pages in that
namespace will
 * no longer be accessible. If you rename it, then you can access them
through
 * the new namespace name.
 *
 * Custom namespaces should start at 100 to avoid conflicting with standard
 * namespaces, and should always follow the even/odd main/talk pattern.
 */
$wgExtraNamespaces =
       array(100 => "Public",
             101 => "Public_Talk",
             102 => "Privileged",
             103 => "Privileged_Talk"
             );

My understanding is that this should create my new namespaces, there
also seems to be a variable for creating "privileged" namespace, but I'm
not sure the what is does differently, i.e. what the difference between
a privileged namespace and a normal namespace.

I also read that new user groups are created directly in the DB, using
SQL. I have no problems with this, though if someone knows of a simpler
way, I wouldn't be averse to hearing about it :-)

The final step in this process is to assign rights based on namespace
and group, not just on a group. I've come across these instructions:
http://meta.wikimedia.org/wiki/Preventing_Access#Setting_permissions_for_a_Group_on_a_whole_new_Namespace,
but was wondering if there's a better way of doing things. That seem
kind of hacky, plus I'd guess it might need to be redone on upgrades of MW.

I have a few more questions:

1) Is there a way of saying that a particular group should take its
rights from one or more other groups, and then modifying specific rights
for itself? ("Rights inheritance", basically.) Alternatively, can a user
be a member of more than one group, and if so, how are conflicting
rights resolved?
2) Is there a convenient way of forbidding all rights to all groups, and
then granting rights access as desirable to the given groups? I realize
that the default rights configuration is largely the "correct" setting
for a normal MW site, but I like the "all things forbidden unless
allowed" since it makes for a very easy to configure website (you'll
here about things that are disallowed but shouldn't be very quickly :-))
plus also maximized out of the box security. Currently my permissions
settings look like this:

$wgGroupPermissions['*'    ]['createaccount']   = true;
$wgGroupPermissions['*'    ]['read']            = true;
$wgGroupPermissions['*'    ]['edit']            = false;
$wgGroupPermissions['*'    ]['createpage']      = false;
$wgGroupPermissions['*'    ]['createtalk']      = false;

$wgGroupPermissions['user' ]['move']            = false;
$wgGroupPermissions['user' ]['read']            = false;
$wgGroupPermissions['user' ]['edit']            = false;
$wgGroupPermissions['user' ]['createpage']      = false;
$wgGroupPermissions['user' ]['createtalk']      = false;
$wgGroupPermissions['user' ]['upload']          = false;
$wgGroupPermissions['user' ]['reupload']        = false;
$wgGroupPermissions['user' ]['reupload-shared'] = false;
$wgGroupPermissions['user' ]['minoredit']       = false;

$wgGroupPermissions['autoconfirmed']['autoconfirmed'] = false;
$wgGroupPermissions['bot'  ]['bot']             = true;

$wgGroupPermissions['bot'  ]['autoconfirmed']   = true;

$wgGroupPermissions['sysop' ]['edit']            = true;
$wgGroupPermissions['sysop']['createpage']      = true;
$wgGroupPermissions['sysop']['createtalk']      = true;
$wgGroupPermissions['sysop']['block']           = true;
$wgGroupPermissions['sysop' ]['minoredit']       = true;

$wgGroupPermissions['sysop']['block']           = true;
$wgGroupPermissions['sysop']['createaccount']   = true;
$wgGroupPermissions['sysop']['delete']          = true;
$wgGroupPermissions['sysop']['deletedhistory']  = true; // can view
deleted history entries, but not see or r
estore text
$wgGroupPermissions['sysop']['editinterface']   = true;
$wgGroupPermissions['sysop']['import']          = true;
$wgGroupPermissions['sysop']['importupload']    = true;
$wgGroupPermissions['sysop']['move']            = true;
$wgGroupPermissions['sysop']['patrol']          = true;
$wgGroupPermissions['sysop']['protect']         = true;
$wgGroupPermissions['sysop']['rollback']        = true;
$wgGroupPermissions['sysop']['upload']          = true;
$wgGroupPermissions['sysop']['reupload']        = true;
$wgGroupPermissions['sysop']['reupload-shared'] = true;
$wgGroupPermissions['sysop']['unwatchedpages']  = true;
$wgGroupPermissions['sysop']['autoconfirmed']   = true;

The main problem with this is that I'm not sure I've "shut down" all of
the permissions I want to. Heck, I don't even fully understand some of
the permissions yet :-)

As always, many, many thanks.
Ken

_______________________________________________
MediaWiki-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: How to prevent access of different user groups to different namespaces

James Mohr-3
Sorry about the top post ....

Personally, I would like to see them add an programmable authentication
module. For example before editing or even displaying a page, it calls a
function like is_authorized() which returns 1 or 0. By default the function
returns 1. You can then add any code to check all sorts of security related
issues.

regards,

jimmo

On Tuesday 13 June 2006 00:31, Ken McDonald wrote:

>  From what I've been reading, this seems possible, perhaps even without
> special patches. However, there also seem to be a plethora of different
> ways to go about this, and I'm wondering if the a "standard" way that is
> recommended. I'm running MW 1.6.3, and can upgrade if necessary.
>
> What I'd like to do is create a "Public" namespace. This will be
> editable and mostly configurable to all logged in users. In addition,
> users will be able to edit most "talk" pages, including that from the
> main namespace.
>
> Than Main namespace will be viewable by all (including *), but only
> edited/changed by an "Editors" group.
>
> A "Privileged" group may be created. If so, it will have all of the
> abilities of the Editors group, plus the ability to view/edit a
> "Private" namespace, which none of the lower-level groups can even read.
> The basic intent is that new "official" pages will be developed here,
> and then moved into the main namespace when complete.
>
> Finally, "sysop" will be able to do anything.
>
> Here's the stuff I've put into LocalConfiguration to try to get things
> started:
>
> /**
>  * Additional namespaces. If the namespaces defined in Language.php and
>  * Namespace.php are insufficient, you can create new ones here, for
> example,
>  * to import Help files in other languages.
>  * PLEASE  NOTE: Once you delete a namespace, the pages in that
> namespace will
>  * no longer be accessible. If you rename it, then you can access them
> through
>  * the new namespace name.
>  *
>  * Custom namespaces should start at 100 to avoid conflicting with standard
>  * namespaces, and should always follow the even/odd main/talk pattern.
>  */
> $wgExtraNamespaces =
>        array(100 => "Public",
>              101 => "Public_Talk",
>              102 => "Privileged",
>              103 => "Privileged_Talk"
>              );
>
> My understanding is that this should create my new namespaces, there
> also seems to be a variable for creating "privileged" namespace, but I'm
> not sure the what is does differently, i.e. what the difference between
> a privileged namespace and a normal namespace.
>
> I also read that new user groups are created directly in the DB, using
> SQL. I have no problems with this, though if someone knows of a simpler
> way, I wouldn't be averse to hearing about it :-)
>
> The final step in this process is to assign rights based on namespace
> and group, not just on a group. I've come across these instructions:
> http://meta.wikimedia.org/wiki/Preventing_Access#Setting_permissions_for_a_
>Group_on_a_whole_new_Namespace, but was wondering if there's a better way of
> doing things. That seem kind of hacky, plus I'd guess it might need to be
> redone on upgrades of MW.
>
> I have a few more questions:
>
> 1) Is there a way of saying that a particular group should take its
> rights from one or more other groups, and then modifying specific rights
> for itself? ("Rights inheritance", basically.) Alternatively, can a user
> be a member of more than one group, and if so, how are conflicting
> rights resolved?
> 2) Is there a convenient way of forbidding all rights to all groups, and
> then granting rights access as desirable to the given groups? I realize
> that the default rights configuration is largely the "correct" setting
> for a normal MW site, but I like the "all things forbidden unless
> allowed" since it makes for a very easy to configure website (you'll
> here about things that are disallowed but shouldn't be very quickly :-))
> plus also maximized out of the box security. Currently my permissions
> settings look like this:
>
> $wgGroupPermissions['*'    ]['createaccount']   = true;
> $wgGroupPermissions['*'    ]['read']            = true;
> $wgGroupPermissions['*'    ]['edit']            = false;
> $wgGroupPermissions['*'    ]['createpage']      = false;
> $wgGroupPermissions['*'    ]['createtalk']      = false;
>
> $wgGroupPermissions['user' ]['move']            = false;
> $wgGroupPermissions['user' ]['read']            = false;
> $wgGroupPermissions['user' ]['edit']            = false;
> $wgGroupPermissions['user' ]['createpage']      = false;
> $wgGroupPermissions['user' ]['createtalk']      = false;
> $wgGroupPermissions['user' ]['upload']          = false;
> $wgGroupPermissions['user' ]['reupload']        = false;
> $wgGroupPermissions['user' ]['reupload-shared'] = false;
> $wgGroupPermissions['user' ]['minoredit']       = false;
>
> $wgGroupPermissions['autoconfirmed']['autoconfirmed'] = false;
> $wgGroupPermissions['bot'  ]['bot']             = true;
>
> $wgGroupPermissions['bot'  ]['autoconfirmed']   = true;
>
> $wgGroupPermissions['sysop' ]['edit']            = true;
> $wgGroupPermissions['sysop']['createpage']      = true;
> $wgGroupPermissions['sysop']['createtalk']      = true;
> $wgGroupPermissions['sysop']['block']           = true;
> $wgGroupPermissions['sysop' ]['minoredit']       = true;
>
> $wgGroupPermissions['sysop']['block']           = true;
> $wgGroupPermissions['sysop']['createaccount']   = true;
> $wgGroupPermissions['sysop']['delete']          = true;
> $wgGroupPermissions['sysop']['deletedhistory']  = true; // can view
> deleted history entries, but not see or r
> estore text
> $wgGroupPermissions['sysop']['editinterface']   = true;
> $wgGroupPermissions['sysop']['import']          = true;
> $wgGroupPermissions['sysop']['importupload']    = true;
> $wgGroupPermissions['sysop']['move']            = true;
> $wgGroupPermissions['sysop']['patrol']          = true;
> $wgGroupPermissions['sysop']['protect']         = true;
> $wgGroupPermissions['sysop']['rollback']        = true;
> $wgGroupPermissions['sysop']['upload']          = true;
> $wgGroupPermissions['sysop']['reupload']        = true;
> $wgGroupPermissions['sysop']['reupload-shared'] = true;
> $wgGroupPermissions['sysop']['unwatchedpages']  = true;
> $wgGroupPermissions['sysop']['autoconfirmed']   = true;
>
> The main problem with this is that I'm not sure I've "shut down" all of
> the permissions I want to. Heck, I don't even fully understand some of
> the permissions yet :-)
>
> As always, many, many thanks.
> Ken
>
> _______________________________________________
> MediaWiki-l mailing list
> [hidden email]
> http://mail.wikipedia.org/mailman/listinfo/mediawiki-l

--
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what others
think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info
_______________________________________________
MediaWiki-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: How to prevent access of different user groups to different namespaces

Rotem Liss
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Mohr wrote:

> Sorry about the top post ....
>
> Personally, I would like to see them add an programmable authentication
> module. For example before editing or even displaying a page, it calls a
> function like is_authorized() which returns 1 or 0. By default the function
> returns 1. You can then add any code to check all sorts of security related
> issues.
>
> regards,
>
> jimmo
>

I think this fucntion is already exist (for editing/moving/creating
page), and is called Title::userCan (includes/Title.php). As far as I
understand, you can hook it (or just edit it) and return false if it is
not some public namespace or a talk namespace and the user doesn't have
the necessary permission.

- --
#define Name RotemLiss
#define Mail mailSTRUDELrotemlissDOTcom
#define Site www.rotemliss.com

#define KeyFingerPrint 4AFD 8579 A449 4267 BED9 38E5 6EF8 5B1F EBDE 7AC0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEj+XdbvhbH+veesARAp4RAJ4gzxFTlxGrwp6VptUyI9djdxV55ACeLVoT
kJTZYsDX8wOKJQf5HTiP0Rw=
=yB58
-----END PGP SIGNATURE-----
_______________________________________________
MediaWiki-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: How to prevent access of different user groups to different namespaces

Rob Church
On 14/06/06, Rotem Liss <[hidden email]> wrote:
> I think this fucntion is already exist (for editing/moving/creating
> page), and is called Title::userCan (includes/Title.php). As far as I
> understand, you can hook it (or just edit it) and return false if it is
> not some public namespace or a talk namespace and the user doesn't have
> the necessary permission.

Let us assume that the user performing the following operation has no
rights to "view" Secret:Page.

1. Open up a page the user can edit
2. {{Secret:Page}}
3. Save

Gasp. This is one example of the vast number of means of accessing
content which makes attempting to use wiki software to lock down
access a somewhat awkward process.


Rob Church
_______________________________________________
MediaWiki-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: How to prevent access of different user groups to different namespaces

Rotem Liss
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rob Church wrote:

> On 14/06/06, Rotem Liss <[hidden email]> wrote:
>> I think this fucntion is already exist (for editing/moving/creating
>> page), and is called Title::userCan (includes/Title.php). As far as I
>> understand, you can hook it (or just edit it) and return false if it is
>> not some public namespace or a talk namespace and the user doesn't have
>> the necessary permission.
>
> Let us assume that the user performing the following operation has no
> rights to "view" Secret:Page.
>
> 1. Open up a page the user can edit
> 2. {{Secret:Page}}
> 3. Save
>
> Gasp. This is one example of the vast number of means of accessing
> content which makes attempting to use wiki software to lock down
> access a somewhat awkward process.
>
>
> Rob Church
>

The site administrator can also prevent editing (for example,
http://grants.wikimedia.org/), but it's not the solution for other wikis
which have, for example, a private part (unviewable and uneditable) and
a public part (viewable and editable).

Therefore, I suggest that the function Title::userCanRead will be called
and checked when viewing a template, and if the user cannot view this
page, an error message will be shown instead of the template.

- --
#define Name RotemLiss
#define Mail mailSTRUDELrotemlissDOTcom
#define Site www.rotemliss.com

#define KeyFingerPrint 4AFD 8579 A449 4267 BED9 38E5 6EF8 5B1F EBDE 7AC0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEj//obvhbH+veesARAjn8AKCHXg5tNPFnaL+BHih3EjW/ftfWFQCfalvy
k0D0udAwo7zO+rrXjKheNoY=
=5I13
-----END PGP SIGNATURE-----
_______________________________________________
MediaWiki-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: How to prevent access of different user groups to different namespaces

Rob Church
On 14/06/06, Rotem Liss <[hidden email]> wrote:
> Therefore, I suggest that the function Title::userCanRead will be called
> and checked when viewing a template, and if the user cannot view this
> page, an error message will be shown instead of the template.

That'll kill caching.


Rob Church
_______________________________________________
MediaWiki-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: How to prevent access of different user groups to different namespaces

James Mohr-3
On Wednesday 14 June 2006 15:11, Rob Church wrote:
> On 14/06/06, Rotem Liss <[hidden email]> wrote:
> > Therefore, I suggest that the function Title::userCanRead will be called
> > and checked when viewing a template, and if the user cannot view this
> > page, an error message will be shown instead of the template.
>
> That'll kill caching.
>
>
> Rob Church

Convenience versus security. Any good admin is always aware of that trade off.
I have two choices tonight:

- Go out to a movie with my wife and kids
- Clean up the Wiki after someone trashed three dozen pages (or worse).

Hmmmm. Sounds like a no-brainer to me. ;-)

regards,

jimmo

--
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what others
think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info
_______________________________________________
MediaWiki-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: How to prevent access of different user groups to different namespaces

James Mohr-3
In reply to this post by Rotem Liss
On Wednesday 14 June 2006 12:33, Rotem Liss wrote:

> James Mohr wrote:
> > Sorry about the top post ....
> >
> > Personally, I would like to see them add an programmable authentication
> > module. For example before editing or even displaying a page, it calls a
> > function like is_authorized() which returns 1 or 0. By default the
> > function returns 1. You can then add any code to check all sorts of
> > security related issues.
> >
> > regards,
> >
> > jimmo
>
> I think this fucntion is already exist (for editing/moving/creating
> page), and is called Title::userCan (includes/Title.php). As far as I
> understand, you can hook it (or just edit it) and return false if it is
> not some public namespace or a talk namespace and the user doesn't have
> the necessary permission.

Very cool! Thanks! I will definately have to take a look at it.

Regards,

jimmo
--
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what others
think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info
_______________________________________________
MediaWiki-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l