Date: Wed, 7 Jul 1999 07:15:47 -0700 (PDT) From: David Wolfskill <dhw@whistle.com> To: jwd@unx.sas.com Cc: freebsd-hackers@freebsd.org Subject: Re: Connect and so on.. Message-ID: <199907071415.HAA71896@pau-amma.whistle.com> In-Reply-To: <199907070227.WAA83834@bb01f39.unx.sas.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>From: "John W. DeBoskey" <jwd@unx.sas.com>
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907071415.HAA71896>