Update the CIL documentation for the in-statement processing and duplicate macro and block declarations with block inheritance. Duplicate macro and block declarations are allowed if they occur as the result of block inheritance. Document the fact that inherited macros are overridden by any macros already declared in a namespace and that declaring a block in a namespace that will inherit a block with the same name can be used to allow in-statements to be used on the block. The new in-statement syntax still supports the old syntax but adds the ability to specify whether the in-statement should be resolved before or after block inheritance is resolved. Signed-off-by: James Carter <jwcart2@gmail.com>
5.7 KiB
Call / Macro Statements
call
Instantiate a macro within the current namespace. There may be zero or more parameters passed to the macro (with zero parameters this is similar to the blockinherit
(call
) / blockabstract
(macro
) statements).
Each parameter passed contains an argument to be resolved by the macro, these can be named or anonymous but must conform to the parameter types defined in the macro
statement.
Macro rules are resolved by searching in the following order:
-
The macro namespace (If found this means that the name was declared in the macro and is now declared in the namespace of one of the parents of the call.)
-
The call arguments
-
The parent namespaces of the macro being called (if any) with the exception of the global namespace.
-
The parent namespaces of the call (if any) with the exception of the global namespace.
-
The global namespace
Statement definition:
(call macro_id [(param ...)])
Where:
|
The |
|
The identifier of the |
|
Zero or more parameters that are passed to the macro. |
Example:
See the macro
statement for an example.
macro
Declare a macro in the current namespace with its associated parameters. The macro identifier is used by the call
statement to instantiate the macro and resolve any parameters. The call statement may be within the body of a macro.
tunable
, in
, block
, blockinherit
, blockabstract
, and other macro
statements are not allowed in macro
blocks.
Duplicate macro
declarations in the same namespace will normally cause an error, but inheriting a macro into a namespace (with blockinherit
) that already has a macro with the same name will only result in a warning message and not cause an error. This behavior allows inherited macros to be overridden with local ones.
Statement definition:
(macro macro_id ([(param_type param_id) ...])
cil_statements
...
)
Where:
|
The |
|
The |
|
Zero or more parameters that are passed to the macro. The The list of valid |
|
The parameter identifier used to reference the entry within the macro body (e.g. |
|
Zero or more valid CIL statements. |
Examples:
This example will instantiate the binder_call
macro in the calling namespace (my_domain
) and replace ARG1
with appdomain
and ARG2
with binderservicedomain
:
(block my_domain
(call binder_call (appdomain binderservicedomain))
)
(macro binder_call ((type ARG1) (type ARG2))
(allow ARG1 ARG2 (binder (call transfer)))
(allow ARG2 ARG1 (binder (transfer)))
(allow ARG1 ARG2 (fd (use)))
)
This example does not pass any parameters to the macro but adds a type
identifier to the current namespace:
(block unconfined
(call add_type)
....
(macro add_type ()
(type exec)
)
)
This example passes an anonymous and named IP address to the macro:
(ipaddr netmask_1 255.255.255.0)
(context netlabel_1 (system.user object_r unconfined.object low_low))
(call build_nodecon ((192.168.1.64) netmask_1))
(macro build_nodecon ((ipaddr ARG1) (ipaddr ARG2))
(nodecon ARG1 ARG2 netlabel_1)
)