Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 beta 3/9/83; site hplabs.UUCP Path: utzoo!linus!decvax!harpo!seismo!hao!hplabs!davis From: davis@hplabs.UUCP (Jim Davis) Newsgroups: net.unix-wizards Subject: Re: A possible security bug fix Message-ID: <1652@hplabs.UUCP> Date: Fri, 29-Jul-83 19:31:20 EDT Article-I.D.: hplabs.1652 Posted: Fri Jul 29 19:31:20 1983 Date-Received: Mon, 1-Aug-83 05:00:39 EDT References: <3563@sri-arpa.UUCP> Organization: Hewlett Packard Labs, Palo Alto CA Lines: 31 With reference to Bob English's comment: "I don't think the '$ foo 2>&-' complaint is a valid one. It could be easily addressed either by '$ foo 2>& /dev/null' or by having the shell itself do the /dev/null connection when the user attempts to disconnect one of the standard outputs." First, the '$ foo 2>& /dev/null' solution has nothing to do with the security aspects. Simply because the user has the option not to attempt to break security does not cause a system to BE secure. Second, the solution of having the shell disallow leaving a standard stream unconnected does solve a small part of the problem. However, it has two disadvantages. One may actually wish to have a standard stream disconnected.(I don't know why, but let's think before we restrict functionality.) A much stronger flaw is that the shell does not spawn all programs. A user wishing to break security will spawn programs by herself. Either programs should be prepared to handle standard streams being unconnected,(the point of the original submission) or the operating system must force all programs to have valid standard streams. I prefer the first approach, others may prefer otherwise. Comments anyone? Jim Davis (James W Davis) ...!ucbvax!hplabs!davis davis.HP-Labs@UDel-Relay ----------------------------------------------------------------