While I wait for feedback on the GroupServer install process, I thought I would
look at some of my open Trac Tickets. At the top is Admin Modification of Group
Members' Email Addresses
https://svn.iopen.net/projects/groupserver/ticket/251
With adequate controls in place, a group administrator should
be able to add a new email address to a user's account.
The phrase “with adequate controls” sums up the core of the problem: without
adequate controls, it is very easy for any administrator to take over all
GroupServer sites!
1. Become a administrator of a group that the site-administrator is in.
2. Add your email address to the site-administrator's account.
3. Remove the site-administrator's email address.
4. Success!
❦
Use Case 1: Mitchel Moves
Mitchel has moved to a new job, so cannot receive email at
mitchel_at_slave.drivers anymore. Unfortunately, she is not recieving any post
from the Knitted Freebies site because
* Mitchel forgot to change her email addresses before changing jobs,
* Mitchel cannot remember her password, and
* Mitchel cannot reset her password because the notification will
go to her old address.
Mitchel asks Nicky to add her new email address to her profile. Nicky adds the
new address, but the old one is left in place. Mitchel gets a email-address
verification message at her new email-account, verifies the address, resets her
password and then deletes her old address.
❦
Use Case 2: Olive Overwhelmed
Olive is overwhelmed with the email that she gets from the Lol Kitten group.
She asks Pat, the administrator for the group, about reducing the email load.
Pat, being a kind-hearted soul — whose generosity has not been sapped by the
unceasing demands of ungrateful users — switches Olive over to Digest mode for
the Lol Kitten group.
❦
Use Case 3: Quincy Quakes
Quincy needs to add his boss, Bertie, to the Führer Flywheel site.
Unfortunately, Quincy typed Bertie's email address in incorrectly. So he
changes it, removing the extra “r”, and the invitation to join the Flywheel
Fans group is resent.
❦
Use Case 4: Sam Bounces
Sam, sunning on a Sahara sojourn, is suddenly swamped by spam. Storage is
stopped by Sam's system service. The Sunday Surfers site suffers a setback:
sendings to Sam are stopped, summarily sent to sender. Stymied, Sam sends Tony
a text, telling of the troubles. Touched, Tony tends to the task. Verily,
verification is vouchsafed. Sam soon sees Sunday Suffers sendings.
[ I have to overthrow a government; I may be some time. ]
The use-cases in my earlier post
http://groupserver.org/r/post/10ivxKPYyOLw1VIkFgngAN
are all based on typical requests, relating to email addresses, that we get at
<email obscured>>. In summary we have:
1. Adding an email address, because the old address is
bouncing (and is now unverified),
2. Altering a users message-delivery settings,
3. Correcting an incorrect (unverified) email address, and
4. Reverifying a message that has become unverified because
of a temporary situation.
(I am quite surprised that they can be pared down to those four, but there you
have it.)
The nice thing about three of the use-cases (1, 3 and 4) is they all are deal
with unverified email addresses! I propose the following rules for editing
email addresses.
* A group administrator or site administrator can only alter a
member's global email settings if — and only if — the member has
*no* verified email addresses. All an administrator can do is
- Add a new address, and
- Send out a verification message for an unverified address.
This rule will allow the administrator to carry out use-cases 1,
3 and 4, but prevent account hijacking.
* A group administrator can alter the *delivery* settings of
any member of the group that he or she administers. This rule
should allow the administrator to carry out use-case 2.
I cannot see any huge security holes in this proposal. Can anyone else?
Have I left any use-cases out?
