From owner-freebsd-stable Fri Mar 31 14:19:14 2000 Delivered-To: freebsd-stable@freebsd.org Received: from mail.oxfam.org.uk (mail.oxfam.org.uk [195.153.200.167]) by hub.freebsd.org (Postfix) with ESMTP id CEAD337B913; Fri, 31 Mar 2000 14:19:05 -0800 (PST) (envelope-from rlake@oxfam.org.pe) Received: from rlake.oxfam.org.pe (root@[209.45.73.61]) by mail.oxfam.org.uk (8.9.3/8.8.5) with ESMTP id XAA02477; Fri, 31 Mar 2000 23:24:50 GMT Received: from localhost (rlake@localhost [127.0.0.1]) by rlake.oxfam.org.pe (8.8.8/8.8.8) with ESMTP id RAA00285; Fri, 31 Mar 2000 17:13:00 -0500 Date: Fri, 31 Mar 2000 17:12:59 -0500 (PET) From: Rici Lake To: David Malone Cc: Jeff Hamilton , freebsd-questions@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: portmap in hosts.allow configuration notes. Was Re: /etc/hosts.allow In-Reply-To: <200003312254.aa61319@salmon.maths.tcd.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 31 Mar 2000, David Malone wrote: > > The twist option cannot work other than in inetd mode. It causes the > > calling process to be replaced (through the execl(3) system call) with an > > configured shell process. If the calling process intended to hang around > > for a while to answer more requests, it's in for a surprise. > > The wrapper library has a variable "resident". It looks like can > be set to indicate that your are a process like portmap, sshd or > sendmail, who doesn't want to be execed out of existance. I guess > this should be set in these programs before any wrapper stuff is > called - I haven't checked to see if it is, but I'll have a look. Yeah, it does. I think you probably could get away with just setting it to 1... from the code, it looks like that would work. However, it does that all by itself. The variable starts at -1, and then it increments it every time it does a check. "Normally", it's called from inetd, so it's only called once and so resident never ascends beyond 0. If you're running some long-standing service which calls the wrapper lib more often, the variable gets incremented past 0 and the library knows that it's there to stay. Then it bans twists. However, this is not part of the public interface. So no-one is going to use that. If you look more closely at the code, you'll see that the request object has a fd member (oops, in c-speak, I mean there's an fd in the request struct. Well, you know what I mean, I hope). That's initialised to -1 when you create the request. Then you eventually get around to setting it if you use the full-bore API to the wrapper library, if you want to. Normally, you wouldn't: I would think that handing the wrapper library the fd for the socket connection would be an invitation to it to do something like a twist. In other words, if you give it an fd, you should expect that it might not return. However, the simple API doesn't have any way of setting that field, so it's going to stay -1. Inetd, on the other hand, is always going to set it. Now the whole point of doing twist echo "Go away, you're bugging me" is to stuff that string down the throat of the socket. It only makes sense to twist if you've got a socket to twist with. So checking the fd for being -1 before you try to twist has got to be the Right Thing to Do. And that would go along with all the other socket related options: banner, set linger, etc. If you don't have a socket, you should still be able to allow, deny, and set logging priority. So I think that would pretty well cover it -- and it would only mean one check for (fd == -1) in each option. I'm going to make that change on my machine, anyway -- but I'm not actually running STABLE any more 'cause I don't feel like upgrading to 4.0 just now (and, to be honest, I've only been FreeBSDing for about a month.) I'm in the middle of writing a libwrappers map for sendmail, if that makes any sense, so I'm sort of immersed in the code at the moment. If there's something I should do with the patch that would be useful to someone, I'm more than happy to share. But obviously, I'm not a FreeBSD insider. R. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message