luci-mod-system: permit sysupgrade --create-backup over rpcd

[JuliusBairaktaris]

cgi-io now delegates archive creation to rpcd's file exec method so that it keeps working when uhttpd runs as a non-root user (see openwrt/openwrt#24558). rpcd gates the exec on the caller's session ACL, so the luci-mod-system-flash ACL must permit the exact command line /sbin/sysupgrade --create-backup -.

Pairs with the cgi-io change.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[JuliusBairaktaris]

@jow- — review ping.

One-line ACL grant permitting exactly /sbin/sysupgrade --create-backup -, in the same luci-mod-system-flash read section as the existing --list-backup grant. rpcd matches the bare executable first and then executable + " " + each param, so this is an exact match with no glob metacharacters.

Needed by openwrt/cgi-io#6, which is in turn needed by openwrt/openwrt#24558.

[openwrt-ai]

Reviewed 2 new commits. Both commit messages match their diffs, both files stay valid JSON, and the ACL strings are in the correct read sections. Two inline notes — the main one is a question about whether rpcd's file.exec can actually carry a backup tarball, since it is fully buffered and returns stdout as a NUL-terminated string.

---

Generated by Claude Code

[openwrt-ai]

The ACL string itself looks right: rpcd checks the bare executable first and then executable + " " + each param joined with spaces (rpc_file_exec_run() file.c:1055-1083), so this is an exact match for today's execl("/sbin/sysupgrade", "/sbin/sysupgrade", "--create-backup", "-", NULL) in cgi-io, and the read section next to --list-backup is the right home for it.

What I can't square is the transport. --create-backup - emits a gzip stream on stdout, and rpcd's file.exec cannot carry that payload:

• stdout is copied into a NUL-terminated blobmsg string (rpc_ustream_to_blobmsg() file.c:889-909), so the archive is cut at the first NUL byte;
• the ustream read buffer is capped at RPC_FILE_MAX_SIZE = 4096 * 64 = 256 KB (file.c:46, file.c:57-59), and filling it aborts the call with UBUS_STATUS_NOT_SUPPORTED (file.c:982-989);
• rpcd master has no fd-passing/streaming exec variant, so there is no way around the buffer.

That limit is precisely why cgi-io exists in the first place — fs.exec_direct() docs, fs.js:404-407 describe /cgi-bin/cgi-exec as the path for "large command outputs which might exceed the ubus message size limits or which contain binary data", and flash.js:83 posts the backup form straight at cgi-backup.

So: does openwrt/cgi-io#6 still spawn and stream the child's stdout to the HTTP client itself, using rpcd only for the privileged spawn / ACL check, or does it go through ubus call file exec? If the latter, any backup over 256 KB (i.e. most of them) fails outright and smaller ones come back truncated at the first NUL. I couldn't read that PR from here, so this may already be handled — worth stating in the commit message either way, since the ACL grant is the only visible half.

The same question applies to the luci-mod-status hunk in this PR: iptables-save / ip6tables-save output on a large ruleset also runs past 256 KB.

---

Generated by Claude Code

[openwrt-ai]

nit: the PR title and description only cover the luci-mod-system backup grant; this second commit adds luci-mod-status entries that aren't mentioned anywhere in the body. Worth widening the title/description (or splitting), so the merge doesn't look like it touched an unrelated module.

For the record the grant itself checks out: nftables.js:163-173`` probes /usr/sbin/iptables-legacy-save with `fs.stat()` (covered by the `/*: [ "list" ]` grant in `luci-base`) and then `fs.exec_direct()`s the bare path with no params, which matches the bare-executable check in rpcd. Both alternatives are real install paths (iptables/Makefile:65 and :485), and although they are symlinks to `xtables-legacy-multi`, rpcd's exec path only canonicalizes textually and never resolves symlinks, so the grant on the link name is the correct one.

---

Generated by Claude Code