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.