There are two use cases where many offline lens operations with the same gold model are performed in succession:
when doing a commit to a front repo, a PUTBACK is performed first, and then many GETs to propagate the update
"reset from gold", GETting all front repos from the gold repo
In these cases, we could save some time by...
loading the gold model,
loading the policy model, and
setting up the security arbiter...
...only once for this bunch of lens executions. This optimization, however, clearly requires some redesign of the offline daemon API + the hook scripts.
Note that the online FW already does this.
Warning: commits can update the MACL file. Using this shared arbiter for the PUTBACK operation should be allowed only if the MACL file is already updated by the commit (and we have already verified that it is allowed to be updated) at the time the lens are executed. If this cannot be made sure, apply the optimization for the GETs only.
There are two use cases where many offline lens operations with the same gold model are performed in succession:
In these cases, we could save some time by...
...only once for this bunch of lens executions. This optimization, however, clearly requires some redesign of the offline daemon API + the hook scripts.
Note that the online FW already does this.
Warning: commits can update the MACL file. Using this shared arbiter for the PUTBACK operation should be allowed only if the MACL file is already updated by the commit (and we have already verified that it is allowed to be updated) at the time the lens are executed. If this cannot be made sure, apply the optimization for the GETs only.