From owner-freebsd-chat Sat Feb 3 10:25:55 2001 Delivered-To: freebsd-chat@freebsd.org Received: from lariat.org (lariat.org [12.23.109.2]) by hub.freebsd.org (Postfix) with ESMTP id EB1D237B4EC for ; Sat, 3 Feb 2001 10:25:37 -0800 (PST) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.org [12.23.109.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id LAA22248; Sat, 3 Feb 2001 11:23:54 -0700 (MST) Message-Id: <4.3.2.7.2.20010203110403.048e78e0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 03 Feb 2001 11:23:44 -0700 To: Rahul Siddharthan , Terry Lambert From: Brett Glass Subject: UNIX-like approach to software and system architecture (Was: D J Bernstein) Cc: j mckitrick , freebsd-chat@FreeBSD.ORG In-Reply-To: <20010203135902.M94275@lpt.ens.fr> References: <200102022245.PAA15968@usr08.primenet.com> <20010202140505.B91552@dogma.freebsd-uk.eu.org> <200102022245.PAA15968@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 05:59 AM 2/3/2001, Rahul Siddharthan wrote: >I admit I'm no expert in programming: but his approach to security >seems to be an innovation already, like using small independent programs >running under their own non-root UIDs, and minimising the number and >power of suid programs needed. Looks obvious, but why didn't >sendmail and bind get there first? Because, even though they grew out of the Berkeley environment, their authors somehow missed the wise lesson of UNIX: Unless there's a compelling need to make things monolithic, small, simple building blocks that can be combined in multiple ways are best. Bernstein's methodology is UNIX-like, whereas the Sendmail and BIND approaches are similar to what we used to see in mainframe apps. Bernstein's dns and mail daemons and smtpd/smtpfwdd are examples of a more UNIX-like approach to system architecture. So, ironically, is BeOS, which has a very small kernel surrounded by a layer of privileged processes. Even the file system and device drivers are walled off in this way. (Admittedly, one motivation for doing the device drivers in this manner was licensing issues -- they wanted to take advantage of the vast number of Linux device drivers but skirt the nastiness of the GPL, which would have required them to reveal all of their source code if they'd put the drivers in the kernel itself. But it is a good choice architecturally, too, so long as you have fast IPC. QNX is somewhat similar.) Apache and the Linux kernel take an approach similar to that of Windows. Both are big blobs, but they're blobs that build themselves at load time from a collection of modules that aren't particularly autonomous. For better or for worse, FreeBSD's kernel is going in the same direction. The "blob which grows by accretion" approach has yielded mixed results in the past; Apache is solid, but Windows is an undebuggable nightmare. It still remains to be seen how FreeBSD will do. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message