luci-app-ffwizard-berlin: invalid permission

[PolynomialDivision]

Using the latest OpenWrt Master to build an Image, the luci-app-ffwizard-berlin can not access important uci configurations and files.

If you add more verbose debug output by placing, e.g.

local profile, err = "profile"..c:get("freifunk","community","name")
local community = "profile_berlin"

if profile ~= false then
		community, err = "profile_"..profile
else
		luci.util.perror(err)
end

E.g. the App can not access the /etc/config/profiles_*. https://github.com/freifunk-berlin/firmware-packages/tree/master/utils/luci-app-ffwizard-berlin/root/usr/share/rpcd/acl.d

[PolynomialDivision]

I think this is just wrong:
https://github.com/freifunk-berlin/firmware-packages/blob/master/utils/luci-app-ffwizard-berlin/luasrc/model/cbi/freifunk/assistent/generalInfo.lua#L23

It has to be

local name = uci:get("profile_"..n, "profile", "name") or "?"

[PolynomialDivision]

Sometimes the ffwizard is accessing config files via the type and sometimes via the name.
Here is an example

config 'community' 'profile'

• Type: community
• Name: profile

Now if we do

local name = uci:get("profile_"..n, "profile", "name") or "?"

we access the name of the community via the name and the name of the section is profile.

If we do

local name = uci:get_first("profile_"..n, "community", "name") or "?"

we access the name of the community via the type and the type is community. Since there could be more than one section of the type community (so we get a list back), we need to do get_first instead of get.

Making things very complicated somtimes the type is called community and sometimes the type is used as name.

I really have no clue why

local name = uci:get_first("profile_"..n, "community", "name") or "?"

is not working. I need help with that. ;)

[PolynomialDivision]

We need permission

{ "read": { "uci": [ "profile_*" ] } }

[PolynomialDivision]

We have to add permission in /usr/share/rpcd/acl.d/luci-app-ffwizard-berlin.json

{
        "luci-app-ffwizard-berlin": {
                "description": "Super user access role",
                "read": {
                        "uci": [ "profile_*" ],
                },
                "write": {
                }
        }
}

[SvenRoederer]

Sometimes the ffwizard is accessing config files via the type and sometimes via the name.
Here is an example

To be honest, all this was confusing me too - always.

EDIT: but fixing this "misuse" should be discussed in a separate issue / PR.

[SvenRoederer]

We have to add here a file, otherwise the wizard is not able to access the /etc/config/profiles_*.
https://github.com/freifunk-berlin/firmware-packages/tree/master/utils/luci-app-ffwizard-berlin/root/usr/share/rpcd/acl.d

A bit more verbose problem description would be helpful (for others) to reproduce / verify the problem. I personally have not ran the wizard for some long time. I suggest to use the Bug-template.

I assume the problem you have seen is very similar to freifunk/openwrt-packages#23. The solution provided by you seem to relate to the OpenWrt-Forum thread referenced by freifunk/openwrt-packages#23 (comment).

[PolynomialDivision]

A bit more verbose problem description would be helpful (for others) to reproduce / verify the problem. I personally have not ran the wizard for some long time. I suggest to use the Bug-template.

I added some useful information and code to debug the luci app.

I assume the problem you have seen is very similar to freifunk/openwrt-packages#23. The solution provided by you seem to relate to the OpenWrt-Forum thread referenced by freifunk/openwrt-packages#23 (comment).

I think my solution in the PR is a better way? :) For me it seems more secure.

[SvenRoederer]

I think my solution in the PR is a better way? :) For me it seems more secure.

Sure, the libuci-lua way might not be able to update uci-settings, as the frontend is not running as root. Also having one lib for reading uci-values and another to write the files via rpc will become really confusing.