mirror of
https://github.com/ChuckBuilds/LEDMatrix.git
synced 2026-08-20 18:09:05 +00:00
ChuckBuilds
324a4e43b1
The installers write two allow-lists, /etc/sudoers.d/ledmatrix_web and
ledmatrix_wifi. Anything the code runs under sudo that is not in one of them
needs a password, which a service cannot supply, so the call fails.
Five commands were being run and none of them granted:
sysctl -w net.ipv4.ip_forward=0|1 wifi_manager.py:788, 883
nft add|delete table ip ledmatrix wifi_manager.py:835, 895
rfkill unblock wifi wifi_manager.py:1811
iptables ... wifi_manager.py:796, 813, 818, 871
mkdir -p .../dnsmasq-shared.d wifi_manager.py:922
Together these are the captive portal: unblock the radio, bring up the AP,
add the redirect, turn on forwarding, and undo all of it afterwards. Without
the grants a hardened install would associate clients to the access point and
then fail to route them.
Why it has gone unnoticed: a stock Raspberry Pi image ships
/etc/sudoers.d/010_pi-nopasswd granting the default user
<user> ALL=(ALL) NOPASSWD: ALL
which satisfies every one of these regardless of what the allow-lists say.
Confirmed on a live rig -- `sudo -n -l` permits sysctl there, and the blanket
rule is why. The allow-lists are effectively decorative on a default image and
only start mattering once that rule is removed or the service runs as another
user.
test_sudo_allowlist_covers_calls.py extracts every argv-style sudo call in
src/ and web_interface/ and asserts an installer grants it, so the next command
added without a rule fails here rather than on someone's hardened box.
Getting that test honest took three passes, each worth recording:
- Matching the literal "systemctl" against rules written as
`$SYSTEMCTL_PATH enable ...` reported six gaps that did not exist. Binary
path variables are now normalised before comparing.
- Scanning the whole installer let `NFT_PATH=$(command -v nft)` -- a variable
definition, not a grant -- satisfy the check on its own, so deleting the
actual nft rules still passed. Only NOPASSWD lines are considered now.
- `sudo -n <tool>` reported "-n" as the binary. sudo's own flags are skipped.
Each of the five grants is individually mutation-checked: removing any one
fails the suite.
(cherry picked from commit a372b43cd1)
Installation Scripts
This directory contains scripts for installing and configuring the LEDMatrix system.
Scripts
one-shot-install.sh- Single-command installer; clones the repo, checks prerequisites, then runsfirst_time_install.sh. Invoked viacurl ... | bashfrom the project root README.install_service.sh- Installs the main LED Matrix display service (systemd)install_web_service.sh- Installs the web interface service (systemd)install_wifi_monitor.sh- Installs the WiFi monitor daemon servicesetup_cache.sh- Sets up persistent cache directory with proper permissionsconfigure_web_sudo.sh- Configures passwordless sudo access for web interface actionsconfigure_wifi_permissions.sh- Grants theledmatrixuser the WiFi management permissions needed by the web interface and the WiFi monitor servicemigrate_config.sh- Migrates configuration files to new formats (if needed)debug_install.sh- Diagnostic helper used when an install fails; collects environment info and recent logs
Usage
These scripts are typically called by first_time_install.sh in the
project root (which itself is invoked by one-shot-install.sh), but
can also be run individually if needed.
Note: Most installation scripts require sudo privileges to install systemd services and configure system settings.