Date: Tue, 26 Nov 1996 11:47:11 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: hackers@frebsd.org Subject: Re: Replacing sendmail Message-ID: <199611261750.LAA17252@brasil.moneng.mei.com> In-Reply-To: <10627.848988232@time.cdrom.com> from "Jordan K. Hubbard" at Nov 25, 96 10:03:52 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> What I mean by this is that while it's relatively easy to quantify > the enable/disable actions for sendmail/qmail, by calling your > utility "pkg_control" you're intimating that this thing will work > effectively for *all* packages which might be enabled or disabled. Please see my other message(s), yes, actually, I would like to see the whole mess evolve in that direction. This could effectively "solve" the problem that lots of people have had with outside vendor packages included in the FreeBSD base distribution, as well. Packages such as Sendmail, BIND, GCC, etc. could all come as "pre-installed packages". This may not be totally compatible with the current paradigm for packages, but do you see what my grand vision is? A user should not HAVE to know that such and such is part of the base system... it should be just as easy to upgrade Sendmail as it is to upgrade "top". Get the latest port/package, and away you go. That is how easy I think it _should_ be. These changes? No, they will not give us that. However, they will at least cause some segregation (even if it IS after-the-fact) to take place, and may provide a mechanism to encourage further refinement along these lines. > To use a totally contrived example, let's say I wanted to disable all > forms of remote login access except for ssh (as many people do). > I would expect to be able to say: > > pkg_control -enable ssh > pkg_control -disable rlogin,telnet > > [yes, I know that rlogin and telnet aren't packages but ssh is, so > already we're into a real grey area, just as with sendmail]. NO!!!!! That is EXACTLY my point, this is NOT a totally contrived example!!!!!!!!!!!!!! You have hit the nail PRECISELY on the head. Joe Random Newbie User should not have to understand the differences between base packages and add on packages. As a matter of fact, he should be able to go to % cd /usr/ports/networking/telnet % make; make install and have it automatically go to Cray, fetch the latest Telnet/Telnetd sources, and automatically upgrade the FreeBSD-shipped binaries. THAT requires segregation of the base system back into the vendor-package areas. THAT would be ultimately cool - and is a benefit that I feel we could attain, even if not immediately. _I_ certainly have a vested interest in making this a reality for Sendmail and BIND. Every time there is a security hole, I have to figure out which machines are likely to be targeted, and upgrade them. Usually not a difficult process, but ALWAYS more difficult than % cd /usr/ports/mta/sendmail % make; make install which should just be able to DTRT. > The actions behind making this happen are quite different than the > sendmail/qmail selection actions, and this package-specific > intelligence has to go *somewhere*, right? Yes, Bury it at a low level. Doing a pkg_control -disable telnetd simply needs to comment out the telnet line in /etc/inetd.conf, and reHUP inetd. pkg_control -disable rcommands requires removing setuid bits on rlogin/etc, and then commenting out the rcommands in /etc/inetd.conf. (Maybe the granularity is wrong, maybe you DO want to be able to target just rlogind, or even on a command by command basis... but you see the bigger picture I think). > Or let's say I wanted to install apsfilter as my default printer > filter. I might want to say: > > pkg_control -enable apsfilter > > Which would entail yet another entirely different set of operations. > > Short of making pkg_control a humongous beast from hell with inate > knowledge of every possible package you might want to enable or > disable, it seems like a generic package control program is something > of a bitch to do, and by calling it "pkg_control" that's exactly what > you're suggesting it does. Precisely. How do you handle that complexity? You make it a dispatcher. It knows nothing other than how to do a few basic things to deal with a request. It is the same way "mount" is supposed to work: mount does not actually know how to mount any filesystems, but it does know how to figure out how to call a filesystem-type-specific mount program. When a "package" is installed, it has an option to also install specific functions that allow it to be enabled or disabled. As these are simply files added to a tree, and also can easily be optional, it is simply extending the functionality of the "ports" or "packages" mechanism (that, at least is how I would prefer to see this work). > That's why I suggest doing this more incrementally by service type. > In my examples, there would actually be something like 3 different > commands: > > mail_control -enable qmail -disable sendmail > > access_control -incoming -enable ssh -disable rlogin,telnet > > lp_control -enable apsfilter > > Each command would have a much easier time of it since it only has to > know about a limited set of services. By keeping the argument names > orthogonal (though I think that -enable and -disable are a bit > stretched in some of these examples :-), it's also easier to write a > front end which can feed them all. As noted, I would prefer to build a foundation first, which would make each of these programs much more trivial to do. > Just my 2 cents. Do you require any change? :-) ;-) I will reiterate: The proposed program - whatever it is called - is simply a small step in the right direction. It does not instantly give us ALL of the potential benefits that I am suggesting! However, it does lay a general foundation for further integration of a "subsystem-ized" model within FreeBSD, and I hope you can see why it is that I feel that this is a really excellent goal to shoot for. It certainly would seem to address so many different concerns. Don't like that we ship with perl4? Hey, it's a base subsystem/package. Just upgrade it to perl5. Don't like Tcl, or the compiler, or <favorite pet peeve>? Hey, it's a base subsystem/package. Remove it. No harm done! Paranoid about security? Don't like setuid bits on things you are not using? Hey, no problem! Disable those packages! Cool, cool, cool, in my very humble opinion. And best of all: it need not cause any additional work for anyone who is not willing to do it. It does not have to be a requirement for doing ports, of course, and those of us who have an interest in providing such functionality for FreeBSD base system "packages" such as Sendmail can do so. Where do you want to go, today? ;-) ... JG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611261750.LAA17252>