From owner-freebsd-hackers Wed Jul 7 7:15:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id 63DDB14BC9 for ; Wed, 7 Jul 1999 07:15:48 -0700 (PDT) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id HAA71896; Wed, 7 Jul 1999 07:15:47 -0700 (PDT) Date: Wed, 7 Jul 1999 07:15:47 -0700 (PDT) From: David Wolfskill Message-Id: <199907071415.HAA71896@pau-amma.whistle.com> To: jwd@unx.sas.com Subject: Re: Connect and so on.. Cc: freebsd-hackers@freebsd.org In-Reply-To: <199907070227.WAA83834@bb01f39.unx.sas.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >From: "John W. DeBoskey" >Date: Tue, 6 Jul 1999 22:27:39 -0400 (EDT) This part may well actually be relevant to -hackers (albeit in a way that will probably seem heretical to some): > Never underestimate the power of good user exits and the >ability to implement your own External Security Manager... [Fair warning: this is long. Sorry; I'm hoping some of it might actually be of interest or use. dhw] Actaully, I have found the "user exit" approach to be extremely powerful as a means of implementing local policy, while maintaining a clear distinction between the vendor-provided codebase & the site's code. It also provided an API for accomplishing these things (though it was a separate API for each "user exit", and the quality of the API thus varied from one exit point to another -- but the "variable quality" aspect is an implementation artifact, more than anything else). Back to -hackers, I've been using and (many times, by necessity) administering UNIX systems since '86. It seems to me that having points within "privileged" code where the OS could invoke site-supplied code on the way in (so the site-supplied code would be able to examine, and possibly replace, a parameter list), the OS could check some sort of "return code" from the site-supplied code (absence of the code being treated as pathologically equivalent to "return code 0"), and either continue processing with the (possibly replaced) parameter list or terminate processing early. then, if processing did take place, just before retunring control to the user-level code, see if there's a post-processing exit point, and if so, pass control to it (first), to perform any additional site-specific policy. The big advantage, it seems to me, is providing these "hooks" so that a given installation, site, machine, or whatever can be customized (possibly fairly extensively)... without touching the OS at all (once the hooks are in place, of course). Granted, with FreeBSD (as well as the other 4.4Lite descendants, and Linux), one has full sources, and can customize it to any extent imaginable. But then re-integrating any such changes in whatever next release of the OS you use can well be a royal pain: since full sources are available, it becomes easy to over-customize... which can contribute to making the re-integration more difficult. The "user exit" approach imposes some discipline; it was originally taken (in the MVS world) because (for example) JES2 was provided in full source form, and folks would make site-specific modifications to the source. Then when it came time to upgrade JES2 or the OS, various things would break in the usual wonderfully pleasant ways familiar to anyone who modifies OSs. This resulted in much whining (typically, in the form of support calls, but also a fair amount of groaning and moaning at SHARE), and IBM decided to impose the dreaded "OCO" ("Object Code Only") policy: no more looking at the microfiche assemply listings for the OS and its components, and many of the data structures (called "control blocks" in MVS) became documented only in that their existence at size was acknowledged, but their contents were intentionally undocumented, so that IBM would be under no obligation (in theory) to document changes to such structures. To counter-balance this, IBM provided several additional "exit points" (as described above). Now, at some point, especially given recent (last month's) history with respect to my employer & IBM, I should highlight a couple of things: * I'm not intending to represent Whistle or IBM in any of this. * The above observations were formed over a period (starting in '69) during which I've dealt with IBM, its products, and IBMers, and the last 30 days haven't had a chance to impact that history a whole lot. And I've never worked for IBM before. * I'm certainly *not* holding up MVS as an example of anything approaching perfection. (The interpretation "Man Versus System" is not for nought.) However, I believe that there were a few good ideas in there, and if the FreeBSD community can learn from others' experiences, that's to the good. Who knows; there might even be a good idea embodied somewhere in some code from Redmond -- but I'll leave it to someone else to discuss that. Anyway, like the stuff the RACF & resource managers, I'm certainly willing to discuss this type of thing in more detail, but I suspect that most folks on -hackers would rather the discussion took place elsewhere (at least for now), so I'll be quiet (on -hackers) for a bit, but welcome out-of-band discussion. Cheers, david -- David Wolfskill dhw@whistle.com UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message