Encasementlib treats all args as security layers

[yyzhuang]

When we want to specify an arg to a security layer, encasementlib mistakenly thinks the arg is another security layer.

`start dylink.r2py encasementlib.r2py sensor_layer.r2py restrict_battery.r2py -- -s 10 nanny_battery_test.r2py

...... User traceback: "dylink.r2py", line 547, in "dylink.r2py", line 408, in dylink_dispatch "dylink.r2py", line 521, in evaluate "encasementlib.r2py", line 242, in "encasementlib.r2py", line 227, in secure_dispatch "dylink.r2py", line 521, in evaluate "sensor_layer.r2py", line 250, in "encasementlib.r2py", line 177, in _secure_dispatch_closure "encasementlib.r2py", line 227, in secure_dispatch "dylink.r2py", line 521, in evaluate "restrict_battery.r2py", line 37, in "encasementlib.r2py", line 177, in _secure_dispatch_closure "encasementlib.r2py", line 221, in secure_dispatch "encasementlib.r2py", line 77, in _layer_code Exception (with class 'exception_hierarchy.FileNotFoundError'): Cannot load security layer '-s'. File not found.`

Here -s is an arg to security layer restrict_battery.r2py.

[JustinCappos]

Said differently, if a security layer wants to have its own arguments, if needs to remove those from callargs (or similar) in the encasement library.

We need this to be documented in a clear way and tested.

On Wed, Jul 29, 2015 at 3:03 AM, Yanyan Zhuang notifications@github.com wrote:

When we want to specify an arg to a security layer, encasementlib mistakenly thinks the arg is another security layer.

`start dylink.r2py encasementlib.r2py sensor_layer.r2py restrict_battery.r2py -- -s 10 nanny_battery_test.r2py

...... User traceback: "dylink.r2py", line 547, in "dylink.r2py", line 408, in dylink_dispatch "dylink.r2py", line 521, in evaluate "encasementlib.r2py", line 242, in "encasementlib.r2py", line 227, in secure_dispatch "dylink.r2py", line 521, in evaluate "sensor_layer.r2py", line 250, in "encasementlib.r2py", line 177, in _secure_dispatch_closure "encasementlib.r2py", line 227, in secure_dispatch "dylink.r2py", line 521, in evaluate "restrict_battery.r2py", line 37, in "encasementlib.r2py", line 177, in _secure_dispatch_closure "encasementlib.r2py", line 221, in secure_dispatch "encasementlib.r2py", line 77, in _layer_code Exception (with class 'exception_hierarchy.FileNotFoundError'): Cannot load security layer '-s'. File not found.`

Here -s is an arg to security layer restrict_battery.r2py.

— Reply to this email directly or view it on GitHub https://github.com/SeattleTestbed/seattlelib_v2/issues/172.

[aaaaalbert]

Compare with this security layer that just pops from callargs:

https://github.com/aaaaalbert/benchmark_repy_v2/blob/master/mutarg-seclayer-init.r2py#L6-L7

[aaaaalbert]

OK, security layers that take a fixed number of arguments can just modify the callargs list accordingly.

Layers that take a variable number of arguments can perhaps steal the idea described in aaaaalbert/repy_v2@577526e1cf6d46832052e5b6939623982f863d34: Use -- to signal a change in the target for the next couple of args.

For the "firewall" layer mentioned in the automatic reference above, I could then use things like

x@y !> start encasementlib.r2py firewall.r2py 10--8 -- user_program.r2py
x@y !> start encasementlib.r2py firewall.r2py 10--8 192.168--16 -- user_program.r2py
x@y !> start encasementlib.r2py firewall.r2py 10--8 192.168--16 -- another_layer.r2py singlearg user_program.r2py user_program_arg

(Another, less beautiful, way to solve this would be to not allow any callargs to security layers, but use config files instead.)