Hans Reiser wrote:
George Beshers wrote:

2) The *permissible functionality *of a file system is roughly speaking, the ACLs
    for all the objects in the file system.

    Actually, I think this is a good place to start, because the type "permissible
    functionality" is in fact what the mask is applied to and what is returned.
   Grant you evaluation is done lazily as the execution of an application requires it.

Yes.
I have started re-reading withe Single UNIX Specification with getting a working
definition of permissible functionality in mind.  Have not gotten to Usenix papers
yet or a careful search of ACM.

Does anyone think there is a better starting point?  Or things that are particularly
important to consider?

3)  A user and group instantiated mask forms an *operational set of functionality*.

     What is important here is to recognize that a given executable may have
     different apparent functionality based on who is running it.

I think not in our particular niche.  We do process oriented security, and that is all for now.  Later we can make it more complex.
We can't avoid it at some level without re-writing Linux security.  Take a moment to consider
the set-UID bit on a file which is an executable and I think you will see what I am driving at.

That said, all we need to do is make our specification conform to the smallest code change
for the time being, e.g., the identity mask---what was happening before is what you get.

NB.  I understand that the overriding goal of the first 3 months is devising and demonstrating
that we have a strategy that scales to file systems containing millions of files---but I don't
think we can lose any semantics as fundamental as user/group permissions without inviting
criticism.






Well, for the moment only more questions:

Suppose we have a file system and a mask.  If we were to create a chroot by copying just
the file system

semantic tree (not files, just filenames)

accessible through the mask and run the application in that environment
would the semantics of running the application on the original file system with the mask
by equivalent.  By equivalent I mean no observable difference in the instructions executed
at the user level or the output generated.

No, because new files might be made visible through the mask without the new file creator even being aware that there was a mask.
I don't think my question was very clear ...

For any process, could that process determine if it was running
exclusively by making calls to the reiser4 file system?



Does the question make sense?
Uh no... :-[