From owner-freebsd-security Thu Aug 16 9:34:55 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 529A337B403; Thu, 16 Aug 2001 09:34:48 -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 f7GGYkR97928; Thu, 16 Aug 2001 11:34:46 -0500 (EST) (envelope-from steve@virtual-voodoo.com) Message-ID: <005101c12670$dc57d1a0$28d90c42@eservoffice.com> From: "Steven Ames" To: "Robert Watson" Cc: "Igor Roshchin" , References: Subject: Re: cvs commit: src/etc inetd.conf Date: Thu, 16 Aug 2001 11:31:10 -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 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