From owner-freebsd-hackers  Mon Nov 25 20:01:03 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id UAA05351
          for hackers-outgoing; Mon, 25 Nov 1996 20:01:03 -0800 (PST)
Received: from time.cdrom.com (time.cdrom.com [204.216.27.226])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA05339
          for <hackers@freebsd.org>; Mon, 25 Nov 1996 20:00:50 -0800 (PST)
Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id TAA09147; Mon, 25 Nov 1996 19:50:39 -0800 (PST)
To: Joe Greco <jgreco@brasil.moneng.mei.com>
cc: brantk@atlas.com, peter@taronga.com, hackers@freebsd.org
Subject: Re: Replacing sendmail 
In-reply-to: Your message of "Mon, 25 Nov 1996 21:19:04 CST."
             <199611260319.VAA16166@brasil.moneng.mei.com> 
Date: Mon, 25 Nov 1996 19:50:39 -0800
Message-ID: <9145.848980239@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> Read the thread :-)
> 
> We were talking about a generalized mechanism that could be used to
> disable specific portions of the system (or maybe even remove them).

I did, but I still don't think that this is the kind of thing which
requires one hammer - such a tool would be large and unwieldy.

Rather, I think that this should be handled by a *family* of
configuration tools, each of which handles a distinct type of "package
configuration."  One for mail, one for printing, one for routing, one
for ppp, so on and so forth.

> A tool to manage setuid executables (enable/disable such services)
> by adding or removing the setuid bits is a nice idea, and somewhat
> more useful.

Sort of - each tool needs (or doesn't need) suid privileges for
different reasons, and while they might have the suid bit in common I
don't think that there's much more commonality than that.  You still
want to be able to say things like "priviledged or non-privileged
printing services?", "privileged or non-priviliged email delivery?"
and in each case you're going to do entirely different things to
provide the non-privileged alternative.

This does not suggest a single tool to me.  This suggests, as I said,
at most a family of tools which perhaps adopt some uniform constraints
on argument syntax and such but are still separate.  If we then build
another tool for dispatching the individual tools, perhaps a menuing
shell along the lines of SCO's old "sysadmsh", then that's fine since
it still doesn't have to have inbuilt smarts for every conceivable
type of system administration task.

Perhaps we're in violent agreement here and simply using different
terms, I don't know.

					Jordan