From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 781 invoked from network); 4 Dec 2000 09:06:54 -0000 Received: from sunsite.dk (HELO sunsite.auc.dk) (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 Dec 2000 09:06:54 -0000 Received: (qmail 17873 invoked by alias); 4 Dec 2000 09:06:38 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13217 Received: (qmail 17866 invoked from network); 4 Dec 2000 09:06:36 -0000 Date: Mon, 4 Dec 2000 10:06:34 +0100 (MET) Message-Id: <200012040906.KAA05544@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Sven Wischnowsky's message of Fri, 1 Dec 2000 10:32:50 +0100 (MET) Subject: Re: Last patch I wrote: > I'll have a look at the weekend. Let's see if we can do it with > signal-queueing. I had. It's a nightmare. I haven't yet checked everything, but the patch already has ~3600 lines. The main problem seems to be that we have many places where we get, for example, a pointer to a hash node, keep it in a local variable and later use it. If a trap would be handle between getting the pointer and using it, the handler could do something that invalidates the hash table entry (and hence the pointer). In many places this can quite easily be wrapped inside a queue_signals()/ unqueue_signals() pair but there are places where it is extremly difficult (execcmd(), for example, or the function-autoloading code). Another problem is the module code. Most of this could probably be solved by queue/unqueue pairs (I've done/tried that) and by disallowing to unload modules from a handler. Some (if not most) of the things I haven't tried to make secure yet include the history code and the job- and signal-tables. But even without them, the many queue/unqueue pairs don't look like the right solution. Maybe we should try to identify a hopefully small set of places where we put them, each making a possibly large part of the shell secure and later try to move the pairs further and further down the call chains. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de