[go: up one dir, main page]

Page MenuHomePhabricator

Remove global action related permissions except meta wikimedia
Closed, ResolvedPublic

Description

for traceability and auditability, We should remove following global action related permissions from local "steward" group except meta wikimedia:

  • centralauth-lock
  • centralauth-oversight
  • centralauth-unmerge
  • globalblock

Event Timeline

Rxy triaged this task as Medium priority.Oct 26 2018, 11:43 AM
Rxy moved this task from Backlog to Deploy on the User-Rxy board.
Rxy moved this task from Backlog to To deploy on the Wikimedia-Site-requests board.

Change 469864 had a related patch set uploaded (by Rxy; owner: Rxy):
[operations/mediawiki-config@master] Remove global action related permissions

https://gerrit.wikimedia.org/r/469864

I suppose the reason that the userrights right can't also go is local custom groups that don't appear on meta?

I suppose the reason that the userrights right can't also go is local custom groups that don't appear on meta?

yeah, We need sometimes local userrights right for that reason.

Isn't this group unused anyway (except for Meta)?

Well, other than the use described above, ideally. Theoretically when they do it elsewhere there's https://meta.wikimedia.org/wiki/Stewards/Additional_log_for_global_changes but that relies on manual updates

I suppose the reason that the userrights right can't also go is local custom groups that don't appear on meta?

yeah, We need sometimes local userrights right for that reason.

How often is this a thing?

I don't have an answer to James' question (I imagine you could dig through the userrights log on meta to find out) but I do believe it is a requirement that stewards be able to edit all local groups regardless of whether the group exists at meta. Other than the current solution, you could instead require stewards to temporarily add userrights to the global stewards group, but that's actually worse - for the duration that right applies to the global group, any steward can change any rights from anywhere without it getting centrally logged - whereas with the current one, the performing steward first has to grant themselves local steward rights somewhere, making it easy to go to the right wiki and see exactly what the right user did there.
I haven't thought of any other decent solutions that don't involve fixing T14518: Cross-wiki userrights should use groups from target wiki instead local wiki properly.

This comment was removed by Trijnstel.
This comment was removed by Trijnstel.

I think that the local steward group can be completely eliminated from all wikis except meta and wikis outside the centralauth. Local custom groups should not be a problem as they are always assigned and removed by either by local sysops or bureaucrats - I am not aware of any exceptions. Stewards can manage them by assigning themselves to one of these two groups - as I did in a number of cases.

Such changes-through-the-local-group approach also helps with another issue, that of local user right changes not showing on the local user rights log. That is often a source of confusion.

Thanks for comments all. but this ticket is not proposal for drop the local "steward" group or discussing how handles "remotely userrights change" system.
If you hope these,please file a new ticket.

Change 469864 merged by jenkins-bot:
[operations/mediawiki-config@master] Remove global action related permissions

https://gerrit.wikimedia.org/r/469864

Mentioned in SAL (#wikimedia-operations) [2018-10-29T11:19:18Z] <zfilipin@deploy1001> Synchronized wmf-config/InitialiseSettings.php: SWAT: [[gerrit:469864|Remove global action related permissions (T208035)]] (duration: 00m 48s)

Rxy moved this task from Deploy to Done - SWAT deploy on the User-Rxy board.
Rxy moved this task from To deploy to Done on the Wikimedia-Site-requests board.

I think that the local steward group can be completely eliminated from all wikis except meta and wikis outside the centralauth. Local custom groups should not be a problem as they are always assigned and removed by either by local sysops or bureaucrats - I am not aware of any exceptions. Stewards can manage them by assigning themselves to one of these two groups - as I did in a number of cases.

I agree with Rxy about the scope of this task. If you do wish to make a new ticket with this, I suggest double checking that this is indeed always the case.