Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Aug 2001 20:50:44 -0600
From:      "Mike Porter" <mike.porter@xrxgsn.com>
To:        "Robert Watson" <rwatson@FreeBSD.ORG>
Cc:        <arch@FreeBSD.ORG>, <stable@FreeBSD.ORG>
Subject:   Re: Patch to modify default inetd.conf, have sysinstall prompt to edit , inetd.conf
Message-ID:  <025d01c11afd$ee861fe0$0300a8c0@laptop>

next in thread | raw e-mail | index | archive | help

->On Tue, 31 Jul 2001, Mike Porter wrote:
>
>
>Actually, although I'm happy with the current default of enabling SSH for
>now, if there isn't already a sysinstall post-install config twiddle for
>SSH, we should probably add one.  To be honest, a "default all off"
>policy, with the opportunity to enable easily in sysinstall, might be
>better than turning SSH on by default.  Maybe we'll do that for
>5.0-RELEASE :-).


Yes thank you for clarifying.  Although as I mentioned earlier, I managed to
misread your post and thought you were toaling about ssh when you were
talking about ftpd...

>

>This is true--however, the inetd.conf file doesn't lend itself to
>automated management, as it doesn't have an inline "disabled" flag.  To
>disable a service, you comment it out, making it hard for a program to
>distinguish things which are legitimately comments, and things that are
>disabled services.  In the long term, it would probably make sense to
>develop some sort of administrative tool for inetd.conf: however, I
>concluded that doing so prior to 4.4-RELEASE was unlikely, and opted for
>this.  In the future, if such a tool is developed, I'd be happy to slot it
>in instead of invoking EDITOR on it :-).
>
This is an interesting point, though it could also be argued that if there
is a prety tool to do it, many (most?) of the comments in the file are no
longer needed.  The flip side of this, of course is that then you are more
or less forced into using the specialized editor, and there are those who
would prefer not to (at least not all the time).

JUst brainstorming here....but another potential advantage...such a program
could invoke a boot time check of inetd.conf to a stored backup created on
editing, which block stuff like the person who had the "dlip" line in his
inetd.conf.  I suppose the argument AGAINST that is that whoever put that
line in his inetd.conf could as easily have access to the mythical-viinetd
(to borrow from vipw), and this therefore doesn't add much in the way of
*real* security.

Well, I'm going to shut up now before I put my foot in my mouth again.

mike




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?025d01c11afd$ee861fe0$0300a8c0>