[comp.mail.uucp] Somebody invoked uucico -x9 to osu-cis...

perry@ccssrv.UUCP (Perry Hutchison) (09/09/89)

In article <KARL.89Sep7225153@kant.cis.ohio-state.edu>
karl@kant.cis.ohio-state.edu (Karl Kleinpaste) writes:

> And then someone out there had the unmatched _gall_ to request the
> whole of GNU Emacs source with uucico running -x9.
>
> For those of you not familiar, the -x option to uucico invokes debugging ...
> invoking -x9 at YOUR end also puts MY end into -x9 ... [it generated]
> an audit file well in excess of 18Mbytes.
>
> DON'T DO THAT.  ...  If you must, use -x9 long enough to prove that a
> connection works, or to find a problem.  Don't leave it on when you do
> large software transfers from a public archive site such as osu-cis.

OUCH!!  I trust it was unintentional, or at worst the consequences were
unforseen.

By way of preventing such incidents in the future, it sounds to me like
uucico could be patched such that setting -x does _not_ automagically put
the _remote_ end into -x mode.

karl@godiva.cis.ohio-state.edu (Karl Kleinpaste) (09/09/89)

perry@ccssrv.uucp writes:
   OUCH!!  I trust it was unintentional, or at worst the consequences were
   unforseen.

Probably so.  "Never attribute to malice what can be adequately
explained by stupidity" and other trite thoughts apply.

   uucico could be patched such that setting -x does _not_ automagically put
   the _remote_ end into -x mode.

Probably.  However, I am unimpressed with hacking UUCP source.  Unless
I think of some better solution, I will leave it as I have currently
made it, with the relevant dirs/files chmod'd to prevent them being
opened for write.  Other archive admins might wish to do the same.

--Karl

budd@bu-cs.BU.EDU (Philip Budne) (09/14/89)

karl@godiva.cis.ohio-state.edu (Karl Kleinpaste) writes:

>perry@ccssrv.uucp writes:
>   uucico could be patched such that setting -x does _not_ automagically put
>   the _remote_ end into -x mode.

>Probably.  However, I am unimpressed with hacking UUCP source.  Unless
>I think of some better solution, I will leave it as I have currently
>made it, with the relevant dirs/files chmod'd to prevent them being
>opened for write.  Other archive admins might wish to do the same.

Perhaps a better idea is to implement (in BNU-ish/HDB-ese) a MAXDEBUG
variable in the Permissions file.  Then you can limit "auditing" on a
per-system and/or per-login basis.

-Phil

karl@ficc.uu.net (Karl Lehenbauer) (09/14/89)

Unless it was a local call, whoever did it is probably sorry for financial
reasons.  I've found, at least, that -x9 causes uucico performance to 
superheavily degrade on a 386.
-- 
-- uunet!ficc!karl	"Have you debugged your wolf today?"