Date: Fri, 17 Aug 2001 15:52:57 -0500 From: "Steven Ames" <steve@virtual-voodoo.com> To: "Steven Ames" <steve@virtual-voodoo.com>, "Robert Watson" <rwatson@FreeBSD.ORG> Cc: "Igor Roshchin" <str@giganda.komkon.org>, <security@FreeBSD.ORG> Subject: Re: cvs commit: src/etc inetd.conf Message-ID: <021401c1275e$99119540$28d90c42@eservoffice.com> References: <Pine.NEB.3.96L.1010815134222.81642K-100000@fledge.watson.org> <005101c12670$dc57d1a0$28d90c42@eservoffice.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?021401c1275e$99119540$28d90c42>