Hans Reiser wrote:

> George Beshers wrote:
>
>>  -  There is a *compiled mask* which is designed to optimize *mask
>>
>>>      evaluation*, i.e., the chroot like semantics.
>>>
>>>  -  The mask evaluation is done by the *mask interpreter* which is
>>>     in the kernel (reiser4 area until we take over the world ;-) ).
>>>
>>>  -  That the format produced by tracing can be converted to a
>>>     presentation mask for user editing.
>>
>>
>>
>>
>> Just use the filesystem tree and create a few fall through and bounce 
>> off plugins.
>
>>
>>
>> For the proof of concept I agree.
>
>
> and for the non-proof of concept you would do what?
>
It depends on how useful people find the masks and what extensions 
people start
asking for.

I think mask composition (because of inheritance, group specific access 
rights,
whatever) is likely to be an emerging requirement.  Merging several masks
into a single mask would then be a form of optimization.

I also think that combining masks with other aspects of SELinux, as was 
suggested
in an earlier e-mail, is a potentially quite fruitful phase II scenario.

Another possibility is that simple paths will prove not to be 
sufficient, people
will want/need path patterns.  For example, each user is allowed their own
~user/bin and ~user/lib  and those programs can load .so's from trusted 
libraries
but not from ~user2/lib (for whatever reason).  The point is that in 
this case
is that a common substring is required.

So, for the time being, I will note that trees *are* a really good 
implementation
strategy for the masks that can be specified in my proof of concept proposal
and will wait for a compelling example to justify returning to full REs over
paths or promoting the utility of composition of masks.

Besides, I recently received saga advice about the dangers of "analysis 
paralysis"

    George, trust me, the project will be a LOT more fun if we implement
    the bare minimum
    and get it done early, and then after that spend the rest of the
    time doing what amuses us.

;-)

>>
>> Hans, while your points are valid, they are not compelling.  The 
>> transformations involved
>> have been well understood for 3-4 decades.
>> Ultimately, performance and scalability needs to drive these 
>> implementation/optimization
>> decisions and they can and should wait until we have something 
>> working and can take
>> measurements.
>>
>>> Proposed definition:
>>>
>>>>
>>>>     An extension to the presentation mask language is *syntactic 
>>>> sugar*
>>>>     Iff it does not require increasing the complexity of the mask 
>>>> interpreter.
>>>>
>>>
>>>
>>
>>
>>
>
>