No, it is not. This is like granting an untrusted user access to your system and handing him a SUID enabled text editor. Of course he can overwrite /etc/shadow and set himself a new root password.
Rules in the „read“ scope should cover side-effect free operations, like „read ssh keys“ or „list assiciated stations“ and rules in the „write“ scope should cover operations that alter system state, like „write ssh keys“ or „disable radio“ or „write uci config“.
Below the read/write scope objects there may be „ubus“ and „uci“ rules.
The „ubus“ rules are specified in the form "objectpath": ["list", "of", "functions"] where objectpath refers to a ubus object as seen by ubus list and the function list refers to names of methods exposed by the object. Both object and method names may contain wildcards.
The following ACL would grant access to the network interface status methods:
The ubus rules control which ubus methods may be invoked via the ubus http gateway while the uci rules control which configuration files may be read or written by the ubus methods in the „uci“ path (such as „ubus call uci get“, „ubus call uci set“ etc.)
The ACL names (e.g. „core“, „system“, „status“ in the linked example) are tied to user accounts through the list read and list write options in /etc/config/rpcd.
The following example would declare a user test using the password of user test from /etc/shadow and tie the read scope of the „core“ and „status“ ACLs and the write scope of the „system“ ACL to it:
config login
option username test
option password $p$test
list read core
list read status
list write system
Granting a write scope will always imply granting the corresponding read scope, so
list read foo
list write foo
is equivalent to
list write foo
The read/write options accept wildcards too. You‘ll notice the default root login in the rpcd config which uses
list read *
list write *
This means the root login will get the read/write scope of all defined ACLs granted.
Can you provide a more complete example of the not working script? The above should work, but with unexpected results.
An echo '{ "cmd_result": "$return" }' will literally output { "cmd_result": "$return" } due to the single quote interpolation rules of Bash. You also need to be very careful with proper quoting and escaping when constructing JSON from external input.
Best is to use jshn (JSON Shell Notation) which will take care of constructing proper responses:
#!/bin/sh
# source jshn shell library
. /usr/share/libubox/jshn.sh
# initialize JSON output structure
json_init
# add a boolean field
json_add_boolean foo 0
# add an integer field
json_add_int code 123
# add a string, take care of escaping
json_add_string result "Some complex string\n with newlines\n and even command output: $(date)"
# add an array with three integers
json_add_array alist
json_add_int "" 1
json_add_int "" 2
json_add_int "" 3
json_close_array
# add an object (dictionary)
json_add_object adict
json_add_string foo bar
json_add_string bar baz
json_close_object
# build JSON object and print to stdout
json_dump
# will output something like this:
# { "foo": false, "code": 123, "result": "Some complex string\\n with newlines\\n and even command output: Fri Jul 13 07:11:39 CEST 2018", "alist": [ 1, 2, 3 ], "adict": { "foo": "bar", "bar": "baz" } }