luci-app-mwan3: fix acl error

[ckorber]

Pull request details

Description

rule.js reports an error stating that access to command is denied. This is caused by the call to fs.exec_direct for /usr/libexec/luci-mwan3 ipset dump in the load function.

After adding exec_direct in acl it works.

Screenshot or video of changes (if applicable)

Maintainer (preferred)

@systemcrash @feckert

---

Tested on

OpenWrt version: openwrt-25.12
LuCI version: luci openwrt-25.12
Web browser(s): firefox

---

[openwrt-ai]

Reviewed 1 new commit. The commit message matches its diff, but the change itself looks like a no-op — see the inline comment on the ACL entry.

---

Generated by Claude Code

[openwrt-ai]

exec_direct is a LuCI JS method name, not an rpcd ACL object — so this entry looks like a no-op rather than a fix.

The names under "cgi-io" are the cgi-io applets whose session access is checked (exec for /cgi-bin/cgi-exec, upload, download, backup, read). fs.exec_direct() POSTs to L.env.cgi_base + '/cgi-exec', i.e. it is served by the very same exec applet that is already granted on line 56. Nothing ever asks rpcd for a cgi-io/exec_direct object, so granting it changes no decision.

Supporting evidence in-tree: no ACL file in this repo grants exec_direct (grep -rn exec_direct --include=*.json . is empty), while every other app that calls fs.exec_direct() grants only exec — e.g. luci-app-nlbwmon.json:5, [luci-app-package-manager.json:5](https://github.com/openwrt/luci/blob/66b465cfc5d3a1d95ef7f43ad50321e006a64476/applications/luci-app-package-manager/root/usr/share/rpcd/acl.d/luci-app-package-manager.json#L5),`` luci-mod-network.json:5. The sibling group in this same file ([`luci-app-mwan3-status`, line 5](https://github.com/openwrt/luci/blob/66b465cfc5d3a1d95ef7f43ad50321e006a64476/applications/luci-app-mwan3/root/usr/share/rpcd/acl.d/luci-app-mwan3.json#L5``)) also drives fs.exec_direct() from detail.js:7`` with exec alone.

Since ACL files are only re-read when rpcd reloads, a plausible explanation for "after adding it, it works" is that reinstalling the package/restarting rpcd is what took effect, not the new token. Could you re-test by only restarting rpcd on an unmodified tree?

If the denial does reproduce, the check that is failing is the second one — the "file" scope match on the full command line on line 59. fs.exec_direct('/usr/libexec/luci-mwan3', ['ipset', 'dump']) builds the string /usr/libexec/luci-mwan3 ipset dump, which should match, unless /usr/libexec/luci-mwan3 is a symlink on the test system (rpcd canonicalises the executable path before matching) or the helper is not installed at that path at all. Worth confirming which of the two Access to command denied sites fires before changing the ACL.

Separately, and regardless of the ACL question: rule.js:11 is the only `fs.exec_direct()` call in this app that is *not* wrapped in `L.resolveDefault()`, which is why a failure there blanks the whole Rules page instead of degrading gracefully — its siblings [detail.js:7](https://github.com/openwrt/luci/blob/66b465cfc5d3a1d95ef7f43ad50321e006a64476/applications/luci-app-mwan3/htdocs/luci-static/resources/view/mwan3/status/detail.js#L7)`` and troubleshooting.js:7`` both wrap it. Hardening that call would fix the reported user-visible symptom (a hard error banner) on any system where ipset output is unavailable.

Suggested change

	"exec",
	"exec_direct"
	"exec"

---

Generated by Claude Code