-----BEGIN PGP SIGNED MESSAGE-----

On Sat, 6 Dec 1997, Henry W Miller wrote:

> Most of my message related to number 1, security.  Let me make some
> comments on number 2:  I have some X based files that need to call a
> different executable depending on how many bits per pixel my server is
> running at.  I know that a program should handle this, but for somereason
> this one doesn't, so the next best thing is if I can at least configure
> which program to run based on some userland determinal parameters.
> However I think this belongs in the shells, not in the kernel.  A modified
> shell could have a enviroment "assocate *.gb=vgb%bpp %filename" "assocate
> *.gif xv %filename" and so on, where %bpp is a parameter that can be
> determinded at runtime. (in this case probably by executing a simple 
> program, thouther there are other possibilities.  Then by typing pic.gif
> xv would load.  Would someone suggest this to shell programmers?

I would really object to having this pushed into the shell, let alone
the kernel.  What does this gain us that can't be done by a userland
`open this with the correct util' program?

> And if we must stray then we want to make a clean break that would allow
> us to have a compatibility mode that could not be confused with similear
> functions in the new version.  I'm not againse BSD 5.x if we designe it
> well enough that we can convince (for instance) sun to base solaris 3.x on
> it, freebsd to include it, and so on.  Clearly this is a major undertaking
> and should not be taken lightly, so if at all possibal lets let number 7
> stand until/unless it gets in the way.
> 
> > Competeing/Attractive exisiting relevant things include:
> > 	4. NT-like securuty. (as far as user ID)
> > 	5. Other UNIX's C2/C3 level securty mechinisms

Heh-heh, heh-heh...  He said NT-like security...  As a first step I
propose backing out our recent fixes for the F00F and land bugs...

> If we are doing a new security model, lets go all the way!  I'd like to
> shoot for something that we can start off as just a better model then we
> currently have, but that will allow someone who wants to, to impliment a
> full A1 security model.  I don't need that security, but I think some
> people on this list could use that level of security.  Thus any kernel
> changes should be done with a full formal design, while the user land
> stuff can start out with the minnimun, perhaps not even up to C1
> standards, but a start that someone can hang anything off of.

A1 security requires secret clean-room development at a certified secure
site with certified trusted personel.  We have messy-room development at
a dsitributed site with certifiable personel...

> Well, here are a few more bases, but it is starting to get more and more
> complex instead of less.  I'm already beginning to wonder if anyone out
> there, giving their programing time away for nothing, is willing to do
> this much work.  I'd love to see it done, but I don't have the knowlege to
> do what I just proposed, I would honestly be surprized if anyone who had
> the knowlege is willing to do that much work.  I amke no mistake, it is a
> lot of work.

Sounds like what you want is an interesting system, but not Unix...  In
contrast, one of the most valuable things about NetBSD, IMHO, is that it
_is_ Unix.  Here at FN, for example, we use NetBSD/i386 for smaller
scale work, and then as things grow, we migrate them to Sun's enterprise
harware and SGI's challenge/origin equipment.  A little careful coding
makes this a piece of cake.  (Though I would love to run NetBSD accross
the board, it doesn't yet have support for all of the hardware we use,
and we don't have the staff or time to support a port...

- --
				Jim Wise
				jim.wise@turner.com

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQEVAwUBNIwbQRg+dMhCouwfAQHjNwgAio9lTMq8Dpd4ahDoQ4pZKxeyDIG38vtB
aiBUSJ36IPvAmTf20DPyyoA+94ypUu4a4LlEKzxyoyZXi+2nuDn1BemX1izHOzp1
uPovobSmJK2awip3h7lBTdUKXqHRhp1C+I1rmHpHs48TGRCw3I9jmu8CU8uQUKb9
Xo06Xy+HwTkLTw87t3A0HxAGp2b/2g4a9omHaberwlI2R1cc7b+r/EvtybNjy3vV
sRXEEs1IXleL0iyVJNVGs2FIQe+RVsRFLg9QbRID5DDB86vdk+HqcJtg7pMmktBB
Tf4+vXMwPK6qZPML9rwtZhAcOWg1jjKAzexnBnPXs/j5f83MEwkRjg==
=b3v9
-----END PGP SIGNATURE-----