🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.admin.policy
Article #93

Re: Policy regarding Crack

#93
From: Wes Morgan
Date: Fri, 28 Aug 1992 18:09
114 lines
6009 bytes
S_TITZ@iravcl.ira.uka.de (Olaf Titz) writes:
>2. 'OK, agreed.' (Under the provision that admin's reaction is, for
>instance, writing user a mail telling about it and inviting him for a
>discussion of the matter. Not an immediate account revocation without
>prior notice as is unfortunately common...)

Kneejerk reactions are far too common among admins.  My working policy
(whose approval date keeps changing...8( ) explictly disallows immediate
revocation in all but the most dire circumstances (active cracking, for
instance).

>I knew this was a bad example ;-) but an example of what does happen,
>being justified by the same arguments: alledged non-academic or
>non-study-related use, therefore considered abuse. But I agree that
>your thing is a different issue.

I think that the distinction can be made between "supported non-academic
use" and "individual non-academic use".  Here's two examples:

I install restricted games for all users -> "supported non-academic"
A user builds an unrestricted game for himself  -> "individual non-academic"

(Keep in mind that I do NOT examine user files; a user who built such a
 game would probably go unnoticed UNLESS the system accounting reports
 indicate a significant/unexplained drain on system resources.)

>Here we come to the heart of the issue: a collision of interests of
>users and admins. Is that necessary?
>
>Diskspace quotas are simply a technical need. Space is limited and
>will be filled up, sooner or later. If, however, you have 50 users and
>a 500MB user disk and give each user 1MB of quota, then users may well
>question the setting of the quota *that low*. (I wouldn't call that a
>violation of academic freedom, though.)

If every one of my users went to the limits of their quota, I'd need
about 2 Gb of extra disk......8(

>Take another example: The machine I am currently on prohibits access
>from 9pm to 8am, and there are simply no technical reasons for it, but
>when asking you'll get the answer that it has been introduced because
>of 'hacker' problems (alledgedly 'hackers' have been operating from
>here cracking machines in America, some 3 years ago now). 

Whew....that's rough.

>Playing games is a sensitive issue. Prohibiting that special use (and
>what is a game? Some people think of IRC being a game too) is not
>justified but plaing games on university machines is IMO (!!) not
>justified either. I know of examples of settling the issue by stating
>that playing is not allowed, but will be tolerated unless persons with
>real work want the machines. Given the problems mentioned above, this
>systems works astonishingly well here.

We tried that here, but the results were disastrous; game players refused
to surrender their terminals to academic users, and game playing started
sucking up about 45% of the system's resources.

I think that the time/number-of-users restrictions will work well.  As I
mentioned in earlier postings, I'm going to implement something along the
lines of "If its between 7pm and 7am AND there are fewer than XX users,
you can access these games/MUD clients/IRC clients/etc.".

>It may be considered too general as long it is not stated what
>constitutes a forgery *attempt*. At many sites, all network
>connections are logged, and an admin sweeping through the log files
>(yes, there are people who do that) 

I'm one of those people who reads log files regularly.  Actually, I've
written shell scripts that ignore the 'commonplace' stuff and only
display the 'interesting' entries.

>may see the dreaded '25' and
>conclude immediately an email forgery (where this could have been a
>simple verify as well).

Well, I'd working from the assumption that an actual message (be it
an email message or a Usenet posting) that indicates tampering would
be required.  For instance, we've all seen attempted Usenet forgeries
in which the would-be forger didn't remove every reference to himself.

>I simply prefer a democratic approach over the 'admin
>dictatorship'. (Not intended as a personal insult, of course :-)

No offense was taken; I'm an easygoing guy.  8)

I prefer the notion of a 'leveraged democracy'.

If a majority of my users desire a particular service, AND if that
service can be provided within the resources (and obligations) of
the system(s), then, by all means, let's do it!  However, the question
"can it be provided within the resources?" can only be answered by
the admin; he's the one with the 'global view' of the system.

>>  We will NOT be able to develop a written policy that covers every possible
>>  offense.  Some discretion must be left with the administrators.  
>
>Really? I would like to reformulate the last sentence to: ...must be
>left for case-by-case resolution by the admins *in cooperation with
>the users*. No ordre du mufti, please.

The users should certainly have their chance to address a problem; however,
the admins really should have a "reasonable veto".  I've found that most
of my users accept the rationale behind my decisions, once I've explained
that rationale.  Of course, there are always those who insist that I'm a
moron.    8)

--Wes

-- 
MORGAN@UKCC         |       Wes Morgan       |        ...!ukma!ukecc!morgan 
morgan@ms.uky.edu   | Engineering  Computing |   morgan@wuarchive.wustl.edu
morgan@engr.uky.edu | University of Kentucky | JWMorgan@dockmaster.ncsc.mil
  Mailing list for AT&T StarServer S/E  - starserver-request@engr.uky.edu
Technical Details
Message-ID: <1992Aug28.140932.657@ms.uky.edu>
Path: arc1-ca.pugleaf.net!sparky!uunet!gumby!destroyer!gatech!ukma!morgan
References: <9208271530.AA15830@herodotus.cs.uiuc.edu> <1992Aug27.143847.5244@ms.uky.edu> <1992Aug28.153108.2829@rz.uni-karlsruhe.de>

Show Full Headers
Complete Article Headers
Newsgroups: comp.admin.policy,alt.comp.acad-freedom.talk
Path: arc1-ca.pugleaf.net!sparky!uunet!gumby!destroyer!gatech!ukma!morgan
From: morgan@ms.uky.edu (Wes Morgan)
Subject: Re: Policy regarding Crack
References: <9208271530.AA15830@herodotus.cs.uiuc.edu> 
    <1992Aug27.143847.5244@ms.uky.edu> 
    <1992Aug28.153108.2829@rz.uni-karlsruhe.de>
Message-ID: <1992Aug28.140932.657@ms.uky.edu>
Date: Fri, 28 Aug 1992 18:09:32 GMT
Organization: The Puzzle Palace, UKentucky
Lines: 114