Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!IRO.UMontreal.CA!goutier
From: goutier@IRO.UMontreal.CA (Claude Goutier)
Newsgroups: comp.sys.apollo
Subject: Re: /etc/killall, what is it?
Keywords: undocumented, dangerous
Message-ID: <1990Jul29.031834.2406@IRO.UMontreal.CA>
Date: 29 Jul 90 03:18:34 GMT
References: <551@eba.eb.ele.tue.nl> <1990Jul28.142626.28237@IRO.UMontreal.CA> <1990Jul28.204241.14946@terminator.cc.umich.edu>
Sender: news@IRO.UMontreal.CA
Reply-To: goutier@jsp.umontreal.ca (Claude Goutier)
Organization: Universite de Montreal
Lines: 40

In article <1990Jul28.204241.14946@terminator.cc.umich.edu> rees@citi.umich.edu (Jim Rees) writes:
>I don't consider killall to be dangerous to the system, since it doesn't let
>you kill any process you don't own.  It may be dangerous to individual users,
>but anyone who runs a program named "killall" without first finding out what
>it does deserves whatever they get.

You are right. I pick up a wrong example. Better ones could be:
/etc/suid_exec ou /usr/apollo/bin/pax.

Nevertheless, if /etc/killall is intended to be executed by root, then there
is no reason to make it world executable. Further more, it could have been
placed in /etc/sys5.../killall since it is system V proper.

>Apollo may be occasionally incompetent but I doubt that they are malicious.

I think the same as you. But in marketing, the important is not what is true
but what the customer think about the product. How long did they take to fix
the sendmail bug (trojan, trap door debug...)? Of course, it was not their
program. But remember that I was making comparison between rebutal to include
perl and lack of proper concern for programs they wrote or they distribute as
part of UNIX(TM).

Understand me well. I like Apollo and the Display Manager. But I do not like
any software provider which just kill (in the marketing sense) its product
by not supporting it as it deserved to.

>When you are trying to decide whether to trust a piece of software, you need
>to ask yourself whether you trust its author, and adjust your trust level
>accordingly.  See Ken Thompson's Turing award speech for an excellent
>discussion of this topic.

Not only the author, but the modifier/adaptor, the distributor and so on.
The only practical way is to have the source code. When a problem arise,
one can look and find what is going on. Or one could read the source on spare
time and find problems before they actually happen. This is far more easier to
do than to try to get them in the real life :-)
--
  Claude Goutier              Services informatiques, Universite de Montreal
                              C.P. 6128, Succ "A",         Montreal (Quebec)
  goutier@jsp.umontreal.ca    Canada      H3C 3J7             (514) 343-5617