🚀 go-pugleaf

john@iastate.edu (John Hascall) writes:
>When last we left our intrepid explorers...

Wading through University policy/procedure manuals is more like "Voyage
of the Damned", but I'll take "intrepid explorers"....8)

>Well, here at least, we have a number of people who keep asking for another
>userid for some purpose -- we don't do this.  This is what I was wondering
>about.
>

Ah, I see.  Nope, we only issue one userid per person.  That userid might
represent accounts on several systems, depending on their use; however,
"jbuser01" refers to Joe B User, regardless of the system.

>}>}Section 3: Electronic Mail Policy
>}>}3.4   All mailing lists with more than 10 members must be registered with
>}>}      the ECC staff. [Paragraph 1.21u, CSC]
>	We have mail-lists for each course (for example:
>	math_123@iastate.edu).  Now we create these ourselves, but if
>	we didn't I sure wouldn't want to hear about all of them!

We don't create tham automatically, but they're available to every
instructor on request (with submission of a class roll).

Actually, I'd like to know about them.  It never hurts to have an additional
"usage point" handy when you start compiling statistics.  8)

>}	3) Several students have left this organization without informing
>}	   their list members; as a result, I've been getting dozens of
>}	   messages from users/postmasters complaining about "user unknown"
>}	   email bounces.
>
>	You'll never shake this one....    :-(

Maybe you misunderstood.  I'm talking about students who were RUNNING lists,
not mere participants.  Think about getting 200 complaints about a mailing
list that you didn't even know existed!  Ecch.

>}>How could the existence of a mailing list could be illegal?
>}I know that this particular example has been bounced around for years, but
>}what about a "child porn image list"?  What about a list that passes out
>}credit card numbers?
>
>Well, it seems it is the use which is illegal, not the list.  Surely if
>I was to ask you (as my SysAdmin) to setup such a list I wouldn't ask to
>call it something like ``WeFondleLittleBoys@ms.uky.edu'', but rather
>something ordinary sounding like ``wflb@ms.uky.edu''.  But then again,
>maybe these people are really stupid...

Well, I know that I can't stop any particular person; if they really want
to make it happen, they will.  This provision is there to give "Joe Warez"
a dose of reality before he thinks about using our email to distribute his
cracked programs.

(By the way, I adminster machines for the College of Engineering, engr.uky.edu.
The folks at ms.uky.edu were kind enough to issue a userid to me, but I'm not
affiliated with them.)

>I was thinking of things which can continue `passively'.  Like you created
>an 11-person mailing list, or whatever.

Well, action is "at the discretion of ECC staff".  8)

I explicitly mention that warnings/directives would be given prior to
account suspension in almost all cases.  I may need to clarify that a
bit, but my only "quick draw" revocations have occured when I have found
a user actively attempting to break security (or ignoring my direct in-
structions).  Heck, I usually try at least two or three email messages
for the routine stuff.

>I still have a real problem with possibly interferring with a student's
>academic success for `minor, or apparently unintentional, violation[s]'.
>Certainly if they are a real threat to the system or other users, then
>immediate action is called for.

The last thing I want to do is lock a user out.  That's why restricted
shells are so nice.  If a user is abusing email, I'll give him a restricted
shell that lets him do everything but email.  If a user is abusing the
network facilities, I'll give him a restricted shell that lets him do
everything but telnet/ftp.

We also provide C/FORTRAN/BASIC in our PC labs, so the student can always
do his work there.

>}>Access is restricted BEFORE the guilt of the student is determined?!?
>
>Same comment as above.

Again, "restricted access" doesn't necessarily mean "you can't log in".
I have found that the dextrous use of restricted shells can protect my
systems WHILE allowing the student to complete his work.  

>Overall, I think you have made a really fine effort; I just like
>to play the devil's advocate.  ;-)

Hey, John, that's why I posted the thing!  I wanted to give you folks a 
chance to eyeball this thing before the users get their hands on it.  If
nothing else, you force me to have logical defenses prepared for every
clause; that's more than I can say for some policies (and policy admins)
I've worked with/under in the past.

By the way, some folks have asked (in email) where this is "going from here".
Here's the way I'll be handling it:

	1) Peer review #1 (via Usenet/email)
	2) Peer review #2 (with several of the other computing shops on campus).
	3) User review (I've got about 12 of my heavy student users lined up).
	4) Administrative review (Dean's Office)
	5) University Counsel (the legal eagles)

Step 6 is actual implementation/distribution.  I plan on a yearly review.

--Wes
-- 
 morgan@ms.uky.edu    |Wes Morgan, not speaking for|     ....!ukma!ukecc!morgan
 morgan@engr.uky.edu  |the University of Kentucky's|   morgan%engr.uky.edu@UKCC
 morgan@ie.pa.uky.edu |Engineering Computing Center| morgan@wuarchive.wustl.edu
        "I was going to rip your head off, but I'm past that now."