[cap-talk] Reducing Ambient user authority in a Type Safe /Memory Safe OS.

[Ben Kloosterman]

Hi Rob , 

Actually I have become more interested in non Mutable objects with F#(Caml)
and use non mutable for Asynch IPC between processes ( it solves a lot of GC
related issues) . Completely agree regarding temp and each app should have
its own temp dir that gets cleared ( I did run into a Windows Terminal
Server issue where users were reading each other's files in temp a long time
ago. ). One issue with tmp is System admins often use different disk sets
for this for performance reasons so  tmp/appid prob makes more sense than
under the app dir.

Home is more of an issue. What I don't get Is how to handle say non Mutable
shared departmental doc files or excel files. A COW while great for many
things like logs doesn't go well for things that are mutable in the users
mind eg docs , excel and code files which if made immutable can lead to
version forking which is not really something you want.  Also what about
sharing a file between 2 programs say editors if they are non mutable and
separate for each app each. Lastly what about mixed use ie a Document that
embeds a spreadsheet which updates when the spread sheetchanges.

Note we have no command line. We have services and Batch context but it's
all strongly typed and uses object capabilities . 

Regards,

Ben 

 
<snip>


>In MinorFs ( minorfs.polacanthus.net ) I use a more radical approach.
>The user its home and the temp directory facility should simply be
>considered to be global mutable state that should be avoided. AppArmor
>van
>be used to give only read permissions to this global state, and MinorFs
>provides a private replacement for both provisions.
>Each process gets its own private temp directory that gets removed ones
>the process dies. Each pseudo persistent process (A combination of uid,
>invocation chain, slot and optionally command-line arguments) gets its
>own
>private home directory.
>
>I can imagine that the MinorFs approach to 'no implicitly shared mutable
>state' may be a bit to purist for your liking.
>For your system you may thus consider to go for the somewhat lower
>granularity of the uid-exe combination. This would than be aproximately
>equivalent to static variables in programing languages.
>You may however wish to consider that the invocation chain and sometimes
>the command line arguments are indeed relevant. I would thus suggest
>going
>for the same combination as MinorFs with the exception of the slot.
>This greatly reduces the problems with implicitly shared mutable state
>that we should try to avoid.
>
>For MinorFs a directory is a decomposable unidirectional tree-graph.
>Each node within a directory tree has its own sparse-cap strong path that
>can be delegated as a sub tree, where delegation of a sub tree does not
>give any capabilities to or trough parent nodes. Currently its just
>decomposition and no attenuation (all caps are rw). I still need to find
>some time (or find someone who has some time) to write up a caretaker
>based file-system to accommodate for attenuation and revocation. Adding a
>file-system that implements COW as a composition pattern is also a pretty
>interesting concept that I hope to allocate some time to in the future.
>The concept would be that you could compose a COW directory using a read
>only path (either strong or weak) and a rw strong path.
>
>Ben, I think that MinorFs minus the slots and plus a yet to implement
>caretaker based filesystem for attenuation and revocation would probably
>fill your needs without having to resort to the backwards compatibility
>nightmares that come with the globally mutable versions of $HOME and
>$TMP.
>
>
>
>Rob