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

RESOLVED WORKSFORME

Status

Tree Management
Treeherder
RESOLVED WORKSFORME
3 years ago
3 years ago

People

(Reporter: chmanchester, Unassigned)

Tracking

(Blocks: 1 bug)

Details

(Reporter)

Description

3 years ago
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.

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1032163
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

3 years ago
(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 5

3 years ago
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 :-)
I will let chmanchester answer that!
Thanks for clarifying it!
(Reporter)

Comment 7

3 years ago
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.
Resolution: DUPLICATE → FIXED

Updated

3 years ago
Resolution: FIXED → WORKSFORME

Comment 8

3 years ago
(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.
(Reporter)

Updated

3 years ago
No longer blocks: 1178524
You need to log in before you can comment on or make changes to this bug.