Keep contact address on file for accounts

[adehnert]

It would be useful for a couple reasons to have email addresses on file for lockers. signup could prompt for this information and store it in LDAP, and then pony could allow further changes.

Uses of this data could include:

• reporting compromised apps
• reporting upgrade failures of apps
• possibly automatically poking people whose apps are generating a lot of error_log spew
• subscribing users to scripts-announce or informing certain users (old Mediawiki's, say) of upgrades

There is a consensus that "forwarding mail of people not signed up for mail_scripts" is *not* a good use, and those people should bounce.

There's also a question of how to initially populate the database, though I think that should be out-of-scope for this ticket.

[andersk]

From my zephyrs:

We absolutely want this in some form. I think the biggest worry before was how to force groups to keep their contact address updated.

The reason that scripts currently uses the locker root’s admin ACL for access instead of some other ACL (e.g. some ACL on web_scripts or a separately maintained list) is that we couldn’t come up with anything else that groups wouldn’t forget to update with transfers of locker control.

I want the right answer to be “email the ACL”, but for many lockers the ACL is too big (e.g. system:cwisfac, or every member of a large student group).

Maybe one answer is to require the contact address to be a user or list that has admin bits on the root of the locker, monitor this condition daily, and yell at someone as soon as it ceases to be the case.

We may need to start yelling sooner, to try to catch contact lists with only users who are soon to be deactivated.

[jdreed]

We may need to start yelling sooner, to try to catch contact lists with only users who are soon to be deactivated.

There's no reason we couldn't involve Scripts in the deactivation process. When the doom list is first generated in November, something could check it for people who are on Scripts ACLs, and either contact them, or only contact them if they're the only person on an ACL, or whatever.

[achernya]

After talking with Anders and Mitch for a bit after the meeting, we came up with the following idea as a starting point:

• Create a web form where users can submit a contact address
• Write an automated script that does some heuristic to figure out what are potential contacts for group lockers
• Use the results of this script to send a mass-mail to users to fill out the web form.
• Potentially: Run this script periodically on lockers that do not have a user-set contact to poke them into doing so, also taking into permission changes

We also discussed if we should display this email on error pages for lockers, and quickly ran into the problem of privacy: we don't want outsiders to be able to harvest email addresses by crafting error pages. One possible solution to this was creating fake addresses that would be forwarded by Scripts, but this is problematic since it opens us up to being considered a SPAM gateway (maybe) so that is a separate problem to solve.

[adehnert]

After slightly more discussion on zephyr, we are okay with also making signup-minimal prompt you if you don't have an address set, though we don't require it.

The finer points of whether or not, and how, to display contact addresses was discussed further and no real consensus seemed to be reached. (-i trac-#193 has more info.)

[adehnert]

There's a lot of neat stuff that could be done with this, and I keep being sad we don't have it, so I'm taking the liberty of bumping the priority.

[ezyang]

We'll need to add an objectType more descriptive than posixAccount, unless we decide to abuse gecos or description for it. It might be simpler for us to abuse them that way: maybe use description?

[adehnert]

It seems like we want to validate that the contact address (at least for MIT addresses, which maybe we want to require) is a user or mailing list with significant overlap with the locker ACL (honestly, I think I'd be tempted to say that if your ACL has at least two members, you need to have at least two people in the overlap... or maybe just whine loudly if you don't). This validation may not be part of the minimum viable product, but it'd be nice to keep it in mind.

I'm real tempted to use GECOS for this (semi-arbitrarily, I'm gonna vote for the second field ("office")), largely to avoid dealing with the LDAP schema...

I think we need access for:

• Pony, or some other web frontend
• signup, or some other user that signup-minimal and other commands run on behalf of locker admins can access[*]
• some user the maintenance cron job can run as (I'd be tempted to make this pony...)

For the command-line use case, I'd envision some setuid signup command that takes a contact address, validates it, fetches the gecos field from LDAP, and writes the new field back (or, if we have a good auth story, a utility that calls some web service that does the same).

AFAICT, daemon/scripts-signup.mit.edu has enough bits already, and giving Pony bits is just a matter of adding an attribute of aci: (target="ldap:///ou=People,dc=scripts,dc=mit,dc=edu")(targetattr="gecos")(version 3.0;acl "pony";allow (write ) userdn="ldap:///uid=daemon/scripts-pony.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu";).

[*] The alternatives to a special privileged user I see are:

• connect to some Pony web service, but I don't think we have a great story for authing from Athena or the scripts servers to Pony
• allow the scripts accounts to change themselves on the LDAP server, but I also don't think we have a way to authenticate them to the LDAP server (I think I maybe got the impression this worked before we added separate LDAP servers?)
• let locker admins authenticate to the LDAP server directly, but I don't think we want to teach LDAP about admof

I could certainly be wrong in my assumption that these approaches are bad.

[adehnert]

Replying to adehnert:

I'm real tempted to use GECOS for this (semi-arbitrarily, I'm gonna vote for the second field ("office")), largely to avoid dealing with the LDAP schema...

Or actually create scriptsAccount or something, which perhaps isn't so hard, and has the advantage of making it easier to add any additional fields we need in the future -- enable mail scripts, whether the contact address should be validated or when we last poked about updating it, ... I have a sneaking suspicion this won't be the last field we want to add. I'd feel a lot more comfortable if somebody who has dealt with LDAP did that, though.