322418 - Tinderbox should require a personal login for editing tree status messages instead of a global password

Status: RESOLVED WONTFIX

(Webtools Graveyard :: Tinderbox, defect)

Description

[Dave Miller [:justdave]]

Too many people know the admin password for tinderbox, and changing it is difficult because it has to be shared with lots of people who will get locked out until they find someone who knows it.

We should instead require a personal login for each user.  The easiest way to do this short term is probably have it ask for the user's Bugzilla login and password, and check for a group membership in Bugzilla to decide if they have access or not.

Comment 1

[Boris Zbarsky [:bzbarsky]]

What about bonsai?  Sheriffs need the ability to open and close the tree, and sheriff has been #developers most of the time recently.  So we need a reasonable set of people who can open/close the tree (or a small set of always-reachable people).

Comment 2

[Robert Helmer [:rhelmer]]

We can continue to use the shared account if we require SSH public keys for the tinderboxes. This will allow us to do away with passwords entirely.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This is about the password for the tinderbox server, not the client machines.

Comment 4

[cls]

This should be done in a way that doesn't require:
a) coupling tinderbox with bugzilla or 
b) writing a whole new authentication scheme .

If we're going to continue with the one level of admin access that we currently have, then this can be easily accomplished by requiring the user to authenticate with the http server before they can access admintree.cgi or doadmin.cgi.  It may require moving those cgis into an admin/ subdir for ease of setup but then the authentication setup is entirely in the hands of the server admin.

If you want to add additional levels so that you have distinct groups that can:
a) open/close a tree
b) edit the status message/rules
c) create/delete trees
then things get a bit more complicated.  Besides setting REMOTE_USER, whatever authentication method would have to set another env variable that would state the access level.  At a glance, mod_authnz_ldap can do this.

Comment 5

[Dave Miller [:justdave]]

yeah, letting apache do the auth would be fine with me. :)  Makes it easier for us to hook it into LDAP and set groups. :)  Also, if the different tasks are done by different CGIs, we can just list a different require-group for each one, and set the groups in LDAP.  Apache will let you do auth controls in a <Files> block, so they wouldn't necessarily have to move.

Comment 6

[cls]

Attachment: v1.0

Here's the simple version.  We remove the password fields & skip the password check if REMOTE_USER is set and count on the admin to properly set up server side authentication.

Comment 7

[cls]

Attachment: v1.1

Fix silly typo - checked in on tbox1_20080527_cls_branch

Comment 8

[Sylvestre Ledru [:Sylvestre]]

Tinderbox isn't maintained anymore. Closing.