179183 - a bunch of people got added to the netscape confidential group

Status: RESOLVED INVALID

(mozilla.org Graveyard :: Server Operations, task)

Description

[Myk Melez [:myk] [@mykmelez]]

basically everyone with an @netscape.com address in bugzilla was added to the
netscape confidential group.  that group is disabled and can't be used anymore.
 we don't want lots of people having access to it who don't need it.  the added
users should be removed from the group

Comment 1

[Myk Melez [:myk] [@mykmelez]]

Hrm, apparently not so many.  There were 776 on it before; now there are 823.

Comment 2

[Bradley Baetz (:bbaetz)]

This is joel's change.

As I pointed out to myk on IRC, this isn't anything they couldn't have had
access to before, just by creating a brand new account @netscape.com, and
letting the userregexp take over. The only people who would have been affected
by this were those who moved their email from [e-mail], rather than
creating a new account

To 'fix' this, just clear the userregexp. Those people who were in the group
already would have permenant entries in the group map, and those that weren't
will lose them automatically when their  derivations are recalculated.

I thought checksetup was meant to print warnings for this, although apparently
it didn't. Joel?

Comment 3

[Gervase Markham [:gerv]]

This does raise an underlying issue, if I understand things right: it used to be
that userregexp was checked on account creation, but now it's checked every time
groups are "re-derived". So, for example, if I remove [e-mail]
from the Netscape Confidential (regexp: .*@netscape.com) group, he'll get
re-added in short order.

Or am I wrong?

Gerv

Comment 4

[Bradley Baetz (:bbaetz)]

gerv: Thats correct. During the creation of joel's aptch on this, he and I
argued over this changing of seantics. He eventually won, mianly because of the
fact mentioned in comment 0 that there was nothing stopping a person with an
@netscape.com email address from creating a new account, and getting access that
way.

Comment 5

[Joel Peshkin]

So, the comments on this have correctly confimred the behavior is as designed,
but this does leave the question of what to do with disabled groups.  We need to
include them in the group derivations because bugs may still be in a disabled
group.  Should there be a mechanism in the group-edit that lets all bugs be
removed from a group in bulk so that the group can be safely further crippled?

Comment 6

[Joel Peshkin]

Since this is correct behavior, marking this Resolved-Invalid

Comment 7

[Gervase Markham [:gerv]]

> He eventually won, mianly because of the
> fact mentioned in comment 0 that there was nothing stopping a person with an
> @netscape.com email address from creating a new account, and getting access that
> way.

That may be true of netscape.com, but it's not true of all domains. For example,
I might want a group for engineers @company.com - I use an @company.com regexp
for simplicity, and manually remove all the managers. But now, they'd get readded.

Gerv

Comment 8

[Dave Miller [:justdave]]

But that wouldn't have worked, either, Gerv...

The way the old system worked, the regexps were only applied on new accounts. 
If you created a group and put a regexp on it, it didn't do didly to the
existing accounts.  So those managers would have gotten that group when they
created their account, and would have it until you got around to removing it. 
Not very secure if you ask me.

The new system makes the regexp always apply, not just at new account creation
time.  If it's matching the wrong people, you shouldn't be using a regexp (and
shouldn't have been before, either)