From owner-freebsd-security Fri Aug 17 13:56:47 2001 Delivered-To: freebsd-security@freebsd.org Received: from virtual-voodoo.com (bdsl.66.12.217.106.gte.net [66.12.217.106]) by hub.freebsd.org (Postfix) with ESMTP id D0A7E37B40A; Fri, 17 Aug 2001 13:56:39 -0700 (PDT) (envelope-from steve@virtual-voodoo.com) Received: from inlafrec (bdsl.66.12.217.40.gte.net [66.12.217.40]) (authenticated) by virtual-voodoo.com (8.11.5/8.11.5) with ESMTP id f7HKuc452329; Fri, 17 Aug 2001 15:56:38 -0500 (EST) (envelope-from steve@virtual-voodoo.com) Message-ID: <021401c1275e$99119540$28d90c42@eservoffice.com> From: "Steven Ames" To: "Steven Ames" , "Robert Watson" Cc: "Igor Roshchin" , References: <005101c12670$dc57d1a0$28d90c42@eservoffice.com> Subject: Re: cvs commit: src/etc inetd.conf Date: Fri, 17 Aug 2001 15:52:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org So... not having heard any feedback... is it worth spending time on it to produce patches to inetd (to handle Option #1) and a command line tool to modify the configuration using either #1 or #2 (below)? Both are pretty straight forward... > On Wed, 15 Aug 2001, Robert Watson wrote: > > > > One of the problems with this solution is that sites frequently modify > > their inetd.conf to add services, such as pop or imap, and that if they > > ran sysinstall to select a template, they would risk squashing their > > current install. > > Absolutely. I was only suggesting a selection of fixed configurations > for initial install. For the "out of the box" approach. Anything past > initial install I get iffy letting a script make decisions for me :) > > > I agree with your thoughts on a menu-driven editor, but doing that > > properly relies on having a machine-parsable file format that supports > > in-band disabling of services. > > Sort of. As others have pointed out, changing our inetd.conf file makes > us different than other UNIX and that's bad from a learning curve/standards > type of position. OTOH, I see two possible ways around this objection: > > 1. The radical approach. Add an option to inetd that tells it to use a > machine > readable file instead of inetd.conf (maybe inetd.db or some such). > My feeling was that our current file. This doesn't really violate POLA as > its > something readily apparent and the admin goes into it with his eyes open. > > 2. Make use of the existing inetd.conf format with some special handling of > comments. Assume that anything starting with '#OFF#' is a usable option > that is currently turned off. Anything else starting with '#' is just a > comment. > While this won't work with a lot of existing inetd.conf files out there it > won't > barf on them either. It just means that instead of being able to just click > the > "ON" button for a disabled option you'll have to use the inetd editor to ADD > a new service. No biggie. Any comments read in, get regurgitated back out > in the order they apear in. Clicking the "OFF" button for an active service > will cause it to be commented out with the "#OFF#" syntax. > > > format didn't lend itself to that, and as such I went with the current > > "spit the user a text editor" over implementing one before 4.4-RELEASE. > > If someone would like to write an editor that understands the syntax and > > semantics of inetd.conf, they should feel free. However, it needs to > > handle the cases where users have custom comments (etc) properly, and be > > able to handle the full scope of valid inetd.conf files, not just the set > > of files it could possibly generate. > > Agreed in all regards. > > -Steve > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message