Page MenuHomePhabricator

Review the 'botadmin' group at mlwiktionary and mlwikisource
Closed, ResolvedPublic



I'd like to bring to discussion the 'botadmin' group both at mlwikisource and mlwiktionary. In both wikis the flag shares the exact same permissions as the 'sysop' group with the only difference that it can be added and removed by bureaucrats. This brings me some concerns as to the configuration of the flag and if it should continue to exist. The same happens to mlwiki by the way.


  • If a bot really needs to have the full sysop package it can be added to the sysop group instead.
  • No need to duplicate group permissions like this, clogging the configuration files. In fact I doubt that they need the exact same permissions as regular sysops need to have.
  • Breaks our doctrine to only allow bureaucrats on very big and with very large consensus to be able to remove sysop flags locally. None of such wikis have bureaucrats able to desysop locally.

In addition to that, the flag has never been of active user or has never been used at all.

Comparison on botadmin at other wikis

The permission exist at other projects which more or less do share the same permissions to do basic sysop stuff such as page deletion. Examples are:


Usage statistics

Proposed outcome

The current situation at those wikis doesn't really make sense at all. Either the botadmin group should have their permissions drastically reviewed and cut down to those really needed by an hypothetical bot doing sysop work, or they can both disappear as this is granting and removing sysops by the back door for no apparent need as the statistics show.

Event Timeline

Urbanecm subscribed.

I think there are only a few of ways we can follow.

  1. We can remove botadmin group at all and force the bot to be regular sysop if they are supposed to be
    1. We can also allow 'crats to remove sysop flag as well
  2. We can use botadmin=sysop directive in all setup files so we will need to change only sysop group and botadmin will be the same
  3. We can create separate groups for all grants sysop have (I don't mean rights because this isn!t needed I think; if there will be deleters they should be able to delete and undelete and browse deleted versions rather than only delete)
    1. In some time we can delete sysop group at all but I do not think it's a good idea; there can be technical sysops that don't need to have right to block users but there can be somebody who will want to do something in all thinks sysops do it (I'm an example, I write bots (sometime adminbots), fight with vandalism, help newbies, regular maintenance work, maintenan abusefilter etc. etc. etc. and I think I used all sysop rihgts at least once)

I think completely removing is the best idea at all. 'Crats have a large amount of trust and stewards usualy do what they say they should do (please correct me @MarcoAurelio if I'm wrong), especially when original discussion is in complete different language (such as Czech, my mother language, is).

But I think somebody should ask in that wikis and ask for their ideas. I can do it but only in English because I can speek (and even understand) only this language at first and bring here ideas raised by the commuinity.

I think there is another way for wikis that didn't used this group at all. At this wikis we can only inform them about our plan to delete the group, delete it after a week and inform we deleted it. This apply to wikis that used it more than three years ago too because probably this is rare case and the same thing can be done by granting regular sysop group to the bot or run the bot without flag under the bot owner account itself (I think all adminbot owners should be at least a sysop and I think they should be a 'crat preferably).

If I'm wrong at some point please correct me. I don't know all things and it isn't possible at all I think.

I'm adding my own user project to keep myself to be informed about progress better than e-mail (as I receive an e-mail about every phab change in site requests).

Change 332329 had a related patch set uploaded (by Urbanecm):
Remove the botadmin group from mlwikisource

I've uploaded a patch that removes the group from mlwikisource as they don't need it (if they didn't used it from 2013). I will appreciate if you'll have a look at it @MarcoAurelio.

I've uploaded a patch that removes the group from mlwikisource as they don't need it (if they didn't used it from 2013). I will appreciate if you'll have a look at it @MarcoAurelio.

Technically LGTM and I'd go ahead and remove them as it's clearly not needed. But I think some sort of notice will be required by devs to go ahead. IMHO not needed as it was never used and has no members. I'll stick to what it is decided here. Thanks.

Change 332329 abandoned by Urbanecm:
Remove the botadmin group from mlwikisource

No need futhermore. If it would be needed, restore it.

Still unused at mlws, no right changes since 2016. I don't think this is needed there. Just remove? @Bawolff what do you think?

MarcoAurelio added a subscriber: Reedy.

@Bawolff @Reedy As security folks, do you think this should follow the same destiny as T190297 or can we just go ahead and remove this as long-time unused?

@Tgr @Bawolff - I plan to move forward with this and remove said groups given the recent issues. As it stands now this is potentially unnaceptable and creates unneded risks.

Change 433136 had a related patch set uploaded (by MarcoAurelio; owner: MarcoAurelio):
[operations/mediawiki-config@master] security: remove dangerous unused groups at mlwik{tionary|isource}

Change 433136 merged by jenkins-bot:
[operations/mediawiki-config@master] security: Remove dangerous unused 'botadmin' group at mlwik{tionary|isource}

Mentioned in SAL (#wikimedia-operations) [2018-05-23T23:10:51Z] <ebernhardson@tin> Synchronized wmf-config/InitialiseSettings.php: T152296: Remove dangerous unused botadmin group at mlwik{tionary|isource} (duration: 01m 10s)

Jdforrester-WMF assigned this task to MarcoAurelio.
Jdforrester-WMF updated the task description. (Show Details)
Jdforrester-WMF subscribed.

Now deployed.