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

    * on a reiser4 file system that is really the root
    * on a reiser4 file system with a mask, or
    * on a reiser4 file system with chroot

/exclusively/ by making calls to the reiser4 file system?

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