GrOuP iD fOr ThE fReEkS (c'MoN, yOu ReAlLy WaNnA hElP uS!)

Dec 3 04:39 UTC 1996

I be postin' like a mug!
Um... ok, i be was told to put diz here, so here it go, mr. Steev-o told me
to
--DOTE!-- put this in here about this group id thing, if anyone reading this
knows anything about this, or even cares, um... tell staff you think that we
should get this thing. we being Freek, Freekman, Grrwoof.  Don't hate us cuz
wez annoying!  Be nize, let uz get diz thing!  We love you!  Bye!

response 2 of 67:

Dec 4 00:01 UTC 1996

Um, its for a channel.  THerefore, it has a functional reason.  I'm not
exactly sure of what kind of 'vanity' thing we might get out of it but oh
well.

response 4 of 67:

Dec 4 01:49 UTC 1996

What is the problem with this?  I've had group logins before.  (Anyone
remember megdan?)  All you need to do is have someone login and give the
password to the other people in the group.  No staff intervention required.
Be careful who you tell, but that goes without saying.

response 6 of 67:

Dec 4 10:05 UTC 1996

TS, the idea is that if meg and dan want to share files, they create a megdan
account with access to the shared files.  Meg and dan each maintain their own
separate accounts, without sharing those passwords.  Both of them have the
password to the "megdan" account.

The idea is that the freeks could do that, too, rather than creating a new
group.

response 8 of 67:

Dec 5 03:09 UTC 1996

What the freeks are asking for in this case is not one shared account, but
a group in /etc/group which will let them share files while still using their
individual accounts.  They haven't stated it very well here, but their reason
for wanting it, I believe, is to be able to share editing of a party noisetab.
Some staffers have raised objections because it would be an administrative
hassle.  A few other staffers have said they wouldn't mind dealing with adding
the occasional group for something like this.  If we are going to allow
multiple people to share a party noisetab, having a file group for those files
seems to me to be a reasonable way to handle it.

response 10 of 67:

Dec 5 10:40 UTC 1996

<imagines a 12 MB /etc/group>

response 12 of 67:

Dec 6 22:48 UTC 1996

I believe that the primary objection from staff to the idea of 
supporting private unix groups is that they create holes when an account 
is reaped. Here's the scenario:

Users a,b,c get a shared unix group, called xxx

User c gets reaped.

A stranger comes along and creates a new account c (same name, new uid).

The above gives the new user "c" the same rights to the files in the xxx 
group, unless someone is careful enough to note that c should be deleted 
from group xxx when it gets reaped.

The probability of it getting noticed at reap time is near zero unless 
it is going to happen automatically. Our reap process would require some 
additional coding and would become slower if we did that. 

I am not aware of all the issues, but this is my current understanding.

response 14 of 67:

Dec 7 06:24 UTC 1996

Only login IDs.

response 16 of 67:

Dec 7 07:47 UTC 1996

cool - since there *IS* a designated difference BETWEEn "members"
adn "voters," why is there such stonewalling about acceptinig
donations (and membership) from NON-voters?
  
this sucks.
imnsho.
  
members are  "70;" voters are "80."  the difference ALREADY EXISTS!

response 18 of 67:

Dec 7 12:48 UTC 1996

And I've never heard of *any* "stonewalling" about accepting donations from
nonvoters or anyone else.

TS, it's not as if this hasn't been discussed at length.  The issue of
verification addresses two concerns, one relating to voting and hence to
membership: anyone who is a member for three [consecutive] months is eligible
to vote, by the bylaws, even if they pay one month at a time, and so state
law requires us to have records of who members are.  We've also been concerned
about our own need, in self-defense, to be able to identify users who are able
to use Grex to go out on the net, anonymously as far as the rest of the net
is concerned.  You and one or two other people have objected loudly to that,
which is fine, but failed to convince most anyone else that all this is some
sort of police-state situation.  You've continued to grumble, loudly but
confusingly, about it at every opportunity, which is pretty irritating.  And
your grumbles cast aspersions at others and ignore reasons that anyone else
puts forth, which is pretty rude & inconsiderate.  If I personally have any
sympathy for any points you may have made on this kind of issue, you're losing
it by the kind of whining my 6-year-old uses to try to wear me down when I've
told him "no" and explained why at length.

response 20 of 67:

Dec 8 04:28 UTC 1996

After thinking about this some, I think if some staff are willing to
set up the groups, and if the members of the group are willing to
cope with the possible security hole a reap could cause, then there is
no reason to refuse this.

response 22 of 67:

Dec 8 16:48 UTC 1996

TO the complaint that the group-reap system causes gaps:
When a set of users creats a group, they are sent a notice which include a
statement like:
"Note that if a user in this group ever gets reaped, you should contact Grex
administration to have that person removed from your group. Otherwise, access
to your group could be gotten by someone other than your desired group."
Fair warning. Who does it hurt, after all, if a stragner (or, more likely,
an enemy) gets access to your group? The system can't easily be hurt, as with
a stolen user login. Really, only the other group members.

response 24 of 67:

Dec 9 05:55 UTC 1996

damn lots of "grumbling, loudly" before women got the vote, blacks got
the vote, japanese were UN-incarcerated, britain left india, individual
persons were "allowed" to vote in *secret*, religion was the province
of the private citizen only, laws *could* be declared "unconstitutional,"
free speech was NOT grounds for imprisonment ... i continue to grumble,
thakyouverymuch.
  
join me.