Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!decvax!harpo!seismo!hao!hplabs!sri-unix!bob@ucla-locus From: bob@ucla-locus@sri-unix.UUCP Newsgroups: net.unix-wizards Subject: Re: A possible security bug fix Message-ID: <3692@sri-arpa.UUCP> Date: Mon, 1-Aug-83 15:18:13 EDT Article-I.D.: sri-arpa.3692 Posted: Mon Aug 1 15:18:13 1983 Date-Received: Wed, 3-Aug-83 04:40:25 EDT Lines: 24 From: Bob EnglishMy comment was in reply to a criticism of a suggestion that exec require the presence of an open stdin, stdout, and stderr. The reason this was suggested was to prevent opens after the exec from falling accidentally into fd's 0, 1 or 2, resulting in interference between program output and diagnostic output. The criticism was indeed that a user might want to close 0, 1, or 2. I replied that re-directing the output to stdio might be wiser. Perhaps exec should open /dev/null itself if 0, 1, or 2 are open (but that sounds like a real bad idea). I'm more worried about what the shell does, anyway. If some hacker wants to close a conventional file descriptor and take his chances on subsequent exec's, I see no reason to stop him. A naive user, however, should be protected from such foolishness. I should point out that I have yet to hear any reasons (good or bad) for allowing 0, 1, or 2 to be closed. The only one I can think of involves the number of keystrokes typed at the command level in currently existing shells... --bob--