From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1220 invoked from network); 4 Dec 2000 10:35:31 -0000 Received: from sunsite.dk (HELO sunsite.auc.dk) (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 Dec 2000 10:35:31 -0000 Received: (qmail 24898 invoked by alias); 4 Dec 2000 10:35:21 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13218 Received: (qmail 24891 invoked from network); 4 Dec 2000 10:35:19 -0000 From: "Bart Schaefer" Message-Id: <1001204103506.ZM12900@candle.brasslantern.com> Date: Mon, 4 Dec 2000 10:35:06 +0000 In-Reply-To: <200012040906.KAA05544@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: Last patch" (Dec 4, 10:06am) References: <200012040906.KAA05544@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (5.0.0 30July97) To: Sven Wischnowsky , zsh-workers@sunsite.auc.dk Subject: Re: Last patch MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Dec 4, 10:06am, Sven Wischnowsky wrote: } } 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. [...] } 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. Yes, that would be my suggestion, with some careful choosing of the large parts. (I'm sorry that I don't have time right now to do much more than offer advice about this -- I'm the busiest with work right now that I've been for some months.) Another thing is that we should recognize that zsh has been working reasonably well without this for a very long time. If we can pick off the places where the shell spends most of its CPU cycles, we can make what problems there are, far less likely. Then worry about covering the rest of the cases as we have opportunity. } 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. [...] } 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). At least the two examples you gave are cases where I think it would be OK to queue signals over a wider span of code. Some signals are blocked for a good portion of execcmd() already, aren't they? (To avoid SIGCHLD races.) } 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. Couldn't attempting unload from a handler be treated the same as from a wrapper, i.e., just set the MOD_UNLOAD flag on the module struct? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net