On Fri, 5 Dec 1997, Paul Evans wrote:

> 
> For my part at least, I'd like to clairify the actual design goals before I get carried away with possible implementations. Assuming anyone wants my deisgn input anyway! ;)
> 
> There are two functional issues we're dealing with:
> 	1. Security -- we want ACL's
> 	2. File assocations -- we want be be able to exexute "file.gif" and see it, or maybe "cd " into file.tar as a 			directory.

And remember both of these came out of a goal of having a multi-leve
filesystem, but ideally we want everything to work with existing file
systems.

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?

> To cliairfy. The goals are, something like:
(some sniped)
> 	2. Enhanced userland utilites are viable. (an "ls" option to show new file details)
> 	4. Kernel modifications should be limited.
> 	6. POSIX compilance should be maintained as far as standard fopen() etc.
> 	7. We're not straying from the standard UNIX way of doing things. (this ain't gonna be BSD5.0 ;))

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

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.

I'm hopeing someone brillent can come up with something that can move back
in forth between our current model and a full A1 system, without 
compromising security beyond what the least security model compromises.
(this includes all the incompatable personal implimentations that might
come up)

> Have I covered the bases for what's on the table? Or am I way off base? (pun, pun)

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.


         ( \       / )       Henry Miller
      |\  ) ) _,,,/ (,,_     mill0440@gold.tc.umn.edu
     /, .-'`~   ~-.  ;-;;,_  http://www.tc.umn.edu/nlhome/g639/mill0440/
    |,4o     -,_. ,  (  `'-'
   '-~~''(_/~~'  `-'\_)