1179016 - Infrastructure for "sheriff only" actions accessible from the Treeherder UI

Status: RESOLVED WORKSFORME

(Tree Management :: Treeherder, defect)

Description

[Chris Manchester (limited bugmail, email directly)]

We'd like to publish certain actions from treeherder only when a sheriff or other L3 ldap user has initiated them, so we know that based on those actions it's safe to do certain sensitive things (mostly trigger jobs, for instance for filling in a revision). This is the solution we'd like to implement for the security problem identified in bug 1168148.

I'm not sure how much work this is, but it's blocking a few things we need to implement to get better information to sheriffs and other watching the tree so we can keep SETA live and shorten our time to identify and back-out regressions.

Comment 2

[Armen [:armenzg]]

Why was this duped? I thought that internally TH knows which users are sheriffs. Cannot we only allow those users to use *new* special buttons?

Comment 3

[Ed Morley [:emorley]]

(In reply to Armen Zambrano G. (:armenzg - Toronto) from comment #2)
> Cannot we only allow those users to use *new* special buttons?

We already have that ability (eg sheriffs menu, cancel all, ...) - just mark those features as such when you implement them.

Comment 4

[Ed Morley [:emorley]]

eg:

Client: https://github.com/mozilla/treeherder/blob/d5ae8deb9f041ce538eee1a5d8d05c60f09e56be/ui/partials/main/thGlobalTopNavPanel.html#L16

Server: https://github.com/mozilla/treeherder/blob/35fce5772d4ec56621be90d767b5ec8f4beeb937/treeherder/webapp/api/refdata.py#L142

Comment 5

[Ed Morley [:emorley]]

To be clearer: Comment 0 mentioned "only when a sheriff or other L3 ldap user has initiated them". The sheriff part is WORKSFORME (see examples in comment 4), the level 3 LDAP part is a dupe of bug 1032163. Though the bug summary mentions only sheriffs (which contradicts comment 0), so if you'd rather mark the bug as WORKSFORME that's fine too :-)

Comment 6

[Armen [:armenzg]]

I will let chmanchester answer that!
Thanks for clarifying it!

Comment 7

[Chris Manchester (limited bugmail, email directly)]

We need to do this based on L3 ldap, but the sheriff permission can be used as a temporary workaround. I don't really want to build things on top of the idea of a sheriff permission, because all we need is the ability to trigger jobs, which is available to any ldap user, but we've acknowledged that these use cases will be most useful to a sheriff.

I only filed because I was told neither was implemented, so this is not a dupe, but if the approach linked in comment 4 can be extended to our use case this is fixed.

Comment 8

[Ed Morley [:emorley]]

(In reply to Chris Manchester [:chmanchester] from comment #7)
> We need to do this based on L3 ldap, but the sheriff permission can be used
> as a temporary workaround. I don't really want to build things on top of the
> idea of a sheriff permission, because all we need is the ability to trigger
> jobs, which is available to any ldap user, but we've acknowledged that these
> use cases will be most useful to a sheriff.

I agree, but until we have bug 1032163 a sheriff permission is all we have (or to be more precise, a Django "is_staff" bit that currently enables a "Sheriffing" menu, allows writing to the visibility APIs and also unfortunately gives admin access to that user to add other uses as staff as well).

> I only filed because I was told neither was implemented, so this is not a
> dupe, but if the approach linked in comment 4 can be extended to our use
> case this is fixed.

The approach in comment 4 is intended for the use case of "only allow people with is_staff to do X", and already existed, so this is worksforme.