|
Grex > Coop7 > #35: How should staff respond to complaints about a particular user? | |
|
| Author |
Message |
| 25 new of 171 responses total. |
rcurl
|
|
response 75 of 171:
| 
May 6 20:06 UTC 1995 |
Why not? I've made this argument, but of course everything about the
system was designed and installed by people, who made all the choices.
All of these things are "rules", and we have zillions of them (it
feels). The real question is, is this or that rule needed? The rule that
passwords must be used is much more common than that they must be
changed, but the latter is not uncommon at all.
|
avi
|
|
response 76 of 171:
|
May 6 22:39 UTC 1995 |
re 64
Punishments? Well gee.. i don't think I really had any...well for one:
(oops, i forgot to put except in there.., ah well)
Since you are making a script to run party, maybe have a gid group
of "noparty" or something, and when it does that script have it
check for the "noparty" group.
The only problem is, and you brought it up, is that this is
a open access system, so if they get put into a group temporarily, then
they could use a psudo and bypass the other uid.
|
steve
|
|
response 77 of 171:
|
May 7 00:22 UTC 1995 |
Quite right. So we have to be more inventive about things.
|
avi
|
|
response 78 of 171:
|
May 7 17:47 UTC 1995 |
(just for the record, i mispelled "pseudo")
One idea (if adjusted) would be that there is a gid group for "party".
And after you run newuser, you wait a set amount of time for your account
to be able to be put into that group. That is rather drastic, though.
The only thing wrong with it is then newbies who need help MUST depend
on a helper to be online. And then this could be used to look like
some sort of tyranny if that idea spreads to the concept of the
group not be just for using party, but for the ability for sending mail,
ftp'ing in, and things like that, which is even worse. So as of now,
nothing really comes to mind.
|
sidhe
|
|
response 79 of 171:
|
May 7 23:49 UTC 1995 |
Precisely. A system is a set of rules. Disqualifying something from
being a rule, just because it is part of the system, is ridiculous. The
question, indeed, with forced password changes, was, do we want this
rule to remain a part of the system. The majority of people said yes, so
that is likely the way it will stay. I am not so vehemently opposed to it
that I would suggest to propose it for an official vote.
But, alas, popcorn, the nice BRIEF list you typed has MANY
underlying rules to make said things enforcable. I wasn't even going to
say that we should get rid of many of these rules- indeed I only listed
a small number. Some of these rules, even, aren't official-
The only reason Sympathy was not set up in the way it must be
set up is an unspoken rule- that is, until I mentioned going against it.
Then much was spoken.
So, no, I'm not saying "Get rid of all the rules". I'm saying
that if, indeed, you think you are sticking to the original premise
of "as few rules as possible", you are fooling yourselves.
|
brenda
|
|
response 80 of 171:
|
May 8 07:36 UTC 1995 |
Let's just give anyone who misbehaves a boot to the head. :)
|
lilmo
|
|
response 81 of 171:
|
May 9 22:53 UTC 1995 |
I'll second that !!
*grin*
|
sidhe
|
|
response 82 of 171:
|
May 11 21:34 UTC 1995 |
That's fine. Simple. Maybe even effective.
Now, anyone have any more serious responses to my #79?
|
ajax
|
|
response 83 of 171:
|
May 11 22:01 UTC 1995 |
I agree that the short list ignores a lot of de facto rules...rules
get embedded into the system, as is sensible and even necessary. The
list also abbreviates a lot; "don't do illegal stuff" is so broad that
it encompasses infinitely more ambiguous subrules (even if the laws aren't
really ambiguous, Grex's legal interpretations are rarely unanimous!).
|
selena
|
|
response 84 of 171:
|
May 12 05:05 UTC 1995 |
Well, if you really wanna know what I thought of 79..
I thought that you made your point, at the cost of being cruel
to these people who work hard to make this as
free as they can.
|
lettermn
|
|
response 85 of 171:
|
Jun 2 00:48 UTC 1995 |
read #78
if a user really wanted to run party avi, they could run party_ instead of
party and then they'd be able to get in... without the script.
|
selena
|
|
response 86 of 171:
|
Jun 2 03:17 UTC 1995 |
Interesting that the avi thing really didn't fit anything
discussed here in this item.. where did the snap decision come from? Where
is the discussion of using this tacitic that avi has recieved?
|
davel
|
|
response 87 of 171:
|
Jun 2 11:54 UTC 1995 |
The original item dealt with complaints that some user is behaving like
a jerk. I don't think breaking into other peoples' accounts & altering
their files has ever been viewed as something we should tolerate. In
this case, things were somewhat muddied by the fact that blob apparently
handed out his password freely. <davel imagines blob getting a quick
kick in the rear> But it's quite different from the kind of nursery-school-
behavior-in-party thing that was under discussion.
|
curby
|
|
response 88 of 171:
|
Jun 2 12:55 UTC 1995 |
Why is rlogin still enabled?
----
The "r" commands are some of the easier things to spoof. Is there some
reason that it is still enabled? If the system needs this enabled,
could we check intos some sort of kerberos access setup? One of the
things that breaks my heart is to see someone that is unix pure set up
the .rhosts file unwittingly. I looked a little last night, and I saw
that there were at least 10 people that had these files in there home
directories. (I broke out not even half way thru the check, so there
are probably more.)
With the type of community that grex draws (the innocents, anlong with
the malicious,) I really think that you sysadm type people should think
about commenting out that service out of inetd.conf.
---
As far as the pretty much criminal behavior of the people that broke
into the other person's account and removed some files, I think that
grex is being way to lenient. Any other comercial service would have
pulled the plug on them without hesitation.
The fact that this discussion is even happening is going a long way to
prove the kind-hearted, well intentioned, basic goodness of the people
that make up this board.
|
mju
|
|
response 89 of 171:
|
Jun 2 13:05 UTC 1995 |
During the initial founders' meetings, we talked a bit about how to
handle system problems (problems with users, security problems, etc.).
The general consensus was that it's best not to have a detailed
written policy on this sort of thing -- i.e., if you delete another
user's file you get 2 weeks without your account, etc. The only thing
a written policy does is let people study it and try to find
loopholes, and remove flexibility in handling situations that come up.
It was also felt that it was better to try to solve a problem with
social methods before resorting to technical solutions. And, as an
aside, it *is* a well-known administrator tactic on a large system to
disable an account (and have it print some sort of message) when you
want to talk to a user about something they've done, you don't want
them using their account until you've talked to them, and it's
impractical to go find them yourself. The result is, of course, that
the user goes to log on and discovers that they can't, and then seeks
you out in short order (because they probably had something they were
logging on to do...).
We try to encourage everyone here to behave like a responsible adult,
regardless of their age. The Grex staff has no desire to act as a
police officer, playground monitor, or parent. If you have a dispute
with another user, we'd like to encourage you and the other user to
work it out on your own, *without* resorting to juvenile tactics like
"flooding" the person or breaking into their account.
|
mju
|
|
response 90 of 171:
|
Jun 2 13:14 UTC 1995 |
(curby slipped in.) I think the main reason we haven't disabled
rlogin & friends is that there *are* people who use them, who
would be adversely affected if they were to be disabled. (I've
heard of at least one instance where a person forgot their password,
but didn't notice for a long time because they usually logged in via
rlogin from a trusted host, so they never had to use their password.)
Most of the problems also aren't with people spoofing rlogin, but with
someone creating a .rlogin file accidentally, or trusting users/hosts
that they shouldn't. It's actually pretty safe to trust a large
system where only trusted people have root; the real problem comes
when you trust a host where anyone might have root access. Kerberos
is a neat idea, but I'm not sure it's viable due to the lack of client
software on most other systems.
|
remmers
|
|
response 91 of 171:
|
Jun 2 16:28 UTC 1995 |
Entirely agree with #89.
|
curby
|
|
response 92 of 171:
|
Jun 3 00:12 UTC 1995 |
I will agree that, so long as root is secure on a system, that rlogin
is somewhat safe. But the real problem here is the knowledge base of
the average user. If a person does not know what a .rhosts file is,
then they cannot know what type of damage can be done by having one.
(And more specifically, checking it once in a while to make sure that
nothing has happened to it.)
Maybe I am paranoid, and maybe I am not giving the average user enough
credit, but it kinda scares me the easability if using and creating
.rhosts files.
Even a simple script that you can call from your .login for people that
use "r"-stuff would probably be helpful. Something along the line of:
-------------------
#!/bin/sh
#
# check .r* files
#
OLDSUM="previously run output"
NEWSUM=`sum -r $HOME/.rhosts`
FARMAIL=OtherAccount@somewhere.else
#
if [ "$NEWSUM" != "$OLDSUM" ] ;then
echo " " | /bin/mail -s ".rhosts file different on `date`" $FARMAIL
fi
#
--------------------
But then, I guess that I am just paranoid...
|
carson
|
|
response 93 of 171:
|
Jun 3 08:15 UTC 1995 |
I don't understand enough Unix to know what .rhosts does. Could
someone briefly describe it for me, via mail, or point me to a
proper reference (maybe the info conference)?
|
lettermn
|
|
response 94 of 171:
|
Jun 3 15:21 UTC 1995 |
carson, if you have someone in your .rhosts file, then they can get into
your account with rlogin, without your password.
|
mju
|
|
response 95 of 171:
|
Jun 3 16:23 UTC 1995 |
(It's usually used to allow you to log into your account from other
machines, without having to type your password. i.e., say you
have an account on M-Net, "carson@arbornet.net". If you wanted
to be able to log into your Grex account from M-Net without a
password, you would put the line "arbornet.net carson" in your
.rhosts. The big problem is that you could just as easily put
someone else's name in the .rhosts line -- i.e., "arbornet.net jep",
and then John Perry would have access to your account from M-Net.)
|
davel
|
|
response 96 of 171:
|
Jun 3 21:44 UTC 1995 |
Some of those rhosts files are likely for real, created by people who
know what they're doing. It's possible that some of them were created
by people who ran scripts suggested (& created) by other people, who
intended to use them as back doors for breaking into others' accounts,
or something like that. If you have a file in your directory called
.rhosts and you didn't create it yourself on purpose, you should at
least read the thing to see who has access to your account. (If you
didn't understand what Marc said about how it works, you can always
try man 5 rhosts & read all about it.)
|
scg
|
|
response 97 of 171:
|
Jun 3 22:55 UTC 1995 |
(M-Net is arbornet.org, not arbornet.net)
|
carson
|
|
response 98 of 171:
|
Jun 4 06:01 UTC 1995 |
Thanks, Ryan, Marc, and Dave!
BTYRSI.
|
rcurl
|
|
response 99 of 171:
|
Jun 4 06:09 UTC 1995 |
This response has been erased.
|