Bug #17338

Enforce configuration of roles in Weblate

Added by zen 2019-12-13 20:14:09 . Updated 2020-04-29 18:35:17 .

Status:
Needs Validation
Priority:
Normal
Assignee:
zen
Category:
Infrastructure
Target version:
Start date:
Due date:
% Done:

40%

Feature Branch:
https://salsa.debian.org/hefee/puppet-tails:hefee/17338-enforce-roles
Type of work:
Sysadmin
Blueprint:

Starter:
Affected tool:
Translation Platform
Deliverable for:

Description

I haven’t followed previous discussion about this, but there’s the idea of enforcing configuration of Weblate roles (as defined in the design doc through configuration management using Puppet.

Roles are:

  • Anonymous users can suggest.
  • Logged in users can suggest and vote on suggestions.
  • Reviewers can accept suggestions.
  • Admin.

The Puppet code created for this might need to be updated when weblate/django’s API changes.

Can someone share some background on this discussion? Was it thought to protect against a specific kind of attack or bug?

Subtasks

Related issues

Blocks Tails - Bug #16881: Puppetize critical Weblate configuration Confirmed

History

#1 Updated by zen 2019-12-13 20:15:14

@hefee, does this issue capture what we wrote down as “puppetize auth model”?

#2 Updated by zen 2019-12-13 20:23:43

  • Assignee set to Sysadmins

#3 Updated by intrigeri 2019-12-14 08:10:35

  • Affected tool set to Translation Platform

#4 Updated by intrigeri 2019-12-14 08:13:15

Hi!

At first glance, this looks like a subset or duplicate of Bug #16881, but the phrasing here is more detailed and could be used to improve the description of Bug #16881 :)

#5 Updated by hefee 2019-12-16 18:00:15

  • blocks Bug #16881: Puppetize critical Weblate configuration added

#6 Updated by hefee 2019-12-16 18:04:34

zen wrote:
> @hefee, does this issue capture what we wrote down as “puppetize auth model”?

yes this sounds what I had in mind in regards of “puppetize auth model”.

What I have in mind with puppetize is any script that is shipped via puppet and is executed regularly like a cronjob.

#7 Updated by hefee 2020-02-21 14:27:18

  • Status changed from New to Needs Validation
  • Assignee changed from Sysadmins to zen
  • Feature Branch set to https://salsa.debian.org/hefee/puppet-tails:hefee/17338-enforce-roles

#8 Updated by zen 2020-02-21 18:02:38

The current proposed fix for this uses a yaml file to store the desired roles. This yaml file was generated from our current setup. We have to review these roles to make sure they match what we want, and we may also want to remove any roles that Weblate creates but are unneeded for us.

#9 Updated by zen 2020-02-21 18:04:32

Talking to hefee, i expressed a bit of worry about future upgrades breaking this solution, one idea he gave was to always run this on check mode and e-mail if expected roles are different than actual roles.

#10 Updated by zen 2020-03-26 19:17:50

  • Status changed from Needs Validation to In Progress
  • Assignee changed from zen to hefee

I have fixed a small typ0 and merged the script as is, to test it. I think it’s a good start but still needs some work:

  • Should we check for unexpected Roles? (i.e. roles not in ACL but that exist in Weblate)
  • Same question for Groups.
  • How about we list exactly which Permissions are missing or should not exist for each Role?
  • Same question for Groups and Roles.
  • Looks like any user in a Group not listed in the ACL will trigger a warning. I think there’s something wrong there.
  • In the future, it’d be great to be able to list superusers and reviewers in the ACL and have this script configure them automatically.

After looking at the script, I don’t have the fear that this will break in the future, for that if it breaks it shouldn’t be hard to fix, and I wouldn’t expect it to cause much trouble (i.e. give wrong permissions to wrong users).

So I think we can improve the script incrementally until it can actually configure/enfoce the ACL by itself.

#11 Updated by intrigeri 2020-04-19 06:19:48

Recent changes that may impact this work: Feature #17514, Feature #17515.

#12 Updated by zen 2020-04-22 12:50:21

We have to double check if we are using the TailsReview@ and TailsAdministration@ groups in Weblate, and properly document that in the design doc where it currently says @Review only.

#13 Updated by hefee 2020-04-23 01:18:01

  • Assignee changed from hefee to zen

I updated the script to make it more useful. So far I see the following output:

WARNING: Unknown group Guests
WARNING: Unknown group Managers
WARNING: Unknown group Owners
WARNING: Unknown group Tails@Administration
WARNING: Unknown group Tails@Review
WARNING: user anonymous is in unknown Guests
WARNING: user admin is in unknown Tails@Administration
WARNING: user muri is in unknown Managers
WARNING: user emmapeel is in unknown Managers
WARNING: user emmapeel is in unknown Tails@Administration
WARNING: user intrigeri is in unknown Managers
WARNING: user intrigeri is in unknown Owners
WARNING: user intrigeri is in unknown Tails@Administration

> Tails@Review and Tails@Administration

As no user is using TailsReview@ we can delete this group easily. TailsAdministration@ is used admin, emmapeel and intrigeri. intrigeri and admin are superusers. So removing this permission only makes difference for emmapeel.

@emmapeel: Do you know what permission do you need to do your work on Weblate without superuser status / aka what groups are needed for administration?

Also we have to find out if we need the Viewers role. It is not described in the design doc and the role itself has no defined permissions. If we need this group than we should update the doc accordingly.

#14 Updated by hefee 2020-04-23 01:32:28

  • Status changed from In Progress to Needs Validation

zen wrote:
> I have fixed a small typ0 and merged the script as is, to test it. I think it’s a good start but still needs some work:
>
> * Should we check for unexpected Roles? (i.e. roles not in ACL but that exist in Weblate)
> * Same question for Groups.

I now print unexpected roles and groups - Well I think unexpected roles and groups won’t hurt anyone, if they are not used by an user.

> * How about we list exactly which Permissions are missing or should not exist for each Role?
> * Same question for Groups and Roles.

I added now a kind of diff output - but in the end the script will enforce those permissions, so the diff output is nice for debugging.

> * Looks like any user in a Group not listed in the ACL will trigger a warning. I think there’s something wrong there.

Well this is one of the key feature of this script - we want to enforce the permissions, so a user in a unexpected groups is a security flaw for each user!

> * In the future, it’d be great to be able to list superusers and reviewers in the ACL and have this script configure them automatically.

Done.

> After looking at the script, I don’t have the fear that this will break in the future, for that if it breaks it shouldn’t be hard to fix, and I wouldn’t expect it to cause much trouble (i.e. give wrong permissions to wrong users).

ACK.

> So I think we can improve the script incrementally until it can actually configure/enfoce the ACL by itself.

ACK.

Because of Feature #17515 we already had a valid case for our script and it managed to detect this.

#15 Updated by hefee 2020-04-23 01:33:09

  • % Done changed from 100 to 40

#16 Updated by emmapeel 2020-04-23 06:36:50

hefee wrote:
> As no user is using TailsReview@ we can delete this group easily. TailsAdministration@ is used admin, emmapeel and intrigeri. intrigeri and admin are superusers. So removing this permission only makes difference for emmapeel.
>
> @emmapeel: Do you know what permission do you need to do your work on Weblate without superuser status / aka what groups are needed for administration?

As emmapeel I cannot access the administration website (https://translate.tails.boum.org/admin/), so when I changed the roles/permissions for example, or when doing similar admin tasks, I log in as the user admin, with the credentials found on the internal repo. I don’t use emmapeel’s account for this.

In the main interface, tho, I feel I get more action items, because of my ‘superuser’ status. As for example with the file uploading (now available for all translators)

I would not mind to drop the privileges on the emmapeel account, so i can experience the limitations of translators-reviewers in that account, while I keep the admin account access to do admin stuff. Although this will mean that there are changes made by admin and we don’t know who did them, and maybe that is not desirable regarding admins accountability (‘but, who did this?!??!?’).

#17 Updated by hefee 2020-04-29 18:35:17

emmapeel wrote:

> I would not mind to drop the privileges on the emmapeel account, so i can experience the limitations of translators-reviewers in that account, while I keep the admin account access to do admin stuff. Although this will mean that there are changes made by admin and we don’t know who did them, and maybe that is not desirable regarding admins accountability (‘but, who did this?!??!?’).

Atm I only aware of three groups: Anonymous, Users, Reviewers and Superusers. The emmapeel account breaks this rules, as it is in Tails@Administration groups.

So I would suggest either downgrade emmapeel account to Reviewers only account or give the account superusers right. I’m in favour of giving emmapeel supersuer rights, so the changes are accountable. @emmapeel?

At least at the moment I don’t see any need for a special “Adminstrators” group. The design doc would need an update, too.