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: <3775@sri-arpa.UUCP> Date: Wed, 3-Aug-83 11:49:23 EDT Article-I.D.: sri-arpa.3775 Posted: Wed Aug 3 11:49:23 1983 Date-Received: Sat, 6-Aug-83 04:11:49 EDT Lines: 26 From: Bob EnglishI think you missed the point. What I am trying to avoid (and remember that I wasn't the one to suggest this) is the sudden and inexplicable appearance of standard error messages in data files. I don't think that's an unreasonable goal, but I don't think it should be the responsibility of individual programs to check such things. I don't remember suggesting that fd's 0, 1, or 2 be immune to close except at the command level (where they cannot be explicitly re-opened). Given that the stdio package exists, and is widely used, I think it makes sense to protect its users in some fashion. A more elegant solution would be to prohibit opens on 0, 1, or 2 until an explicit close has been done by that program. That would, at least, prevent the accidental re-opening of a stdio descriptor (the dup call closes an existing file before opening the new one, so that's no problem). I don't see how this adds complexity. Nor do I see how this is a merge with VMS. In fact, I'm a little confused by your comments altogether. --bob--