From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8455 invoked from network); 10 Oct 1999 17:41:55 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 10 Oct 1999 17:41:55 -0000 Received: (qmail 19527 invoked by alias); 10 Oct 1999 17:41:48 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8190 Received: (qmail 19520 invoked from network); 10 Oct 1999 17:41:48 -0000 Subject: Re: PATCH: 3.0.6/3.1.6: Re: All sorts of file-descriptor strangeness In-Reply-To: <991010155440.ZM2271@candle.brasslantern.com> from Bart Schaefer at "Oct 10, 1999 3:54:40 pm" To: schaefer@candle.brasslantern.com (Bart Schaefer) Date: Sun, 10 Oct 1999 18:41:46 +0100 (BST) Cc: zefram@fysh.org, zsh-workers@sunsite.auc.dk X-Mailer: ELM [version 2.4ME+ PL48 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Zefram Bart Schaefer wrote: >If we continue to limit the FDs on the LHS to 0-9, then we can simply >report EBADF whenever one of the "private" FDs appears on the RHS. Ah yes, a neat solution. This is definitely an improvement over my patch, and doesn't require use to actually shuffle private fds around at all. >I'd further point out that with the /proc/*/fd filesystem available, the >shell would have to go to nearly impossible lengths to prevent its private >FDs from becoming visible; That's a slightly different matter. The shell provides a view of a set of fds which gets passed on to programs run from the shell; this is what the redirections manipulate. Conceptually it has no inherent connection with the actual OS-level fd table of the shell process. Anyone that fiddles with /proc/*/fd for a process that they don't actually control at the fd level is just asking for trouble. -zefram