cbb8ec41e8
* fix: install plugin/base requirements as root so ledmatrix.service can see them
ledmatrix-web.service runs as a non-root user, so "Reinstall plugin
requirements" installed packages into that user's ~/.local site-packages.
ledmatrix.service (the actual display, which loads and runs plugin code)
runs as root and can't see another user's user-site packages, so plugins
with dependencies not already present system-wide would silently fail at
runtime with ModuleNotFoundError even after a "successful" reinstall.
Reproduced and fixed live against a real device (weather plugin's astral
dependency, used for moon-phase data): confirmed the exact failure
("No module named 'astral'" on every almanac cycle) and confirmed it's
gone after this fix.
Adds scripts/fix_perms/safe_pip_install.sh, a root-owned wrapper (mirroring
the existing safe_plugin_rm.sh pattern) that validates the target is
requirements.txt at the project root or under plugin-repos/ or plugins/
before running pip install as root. configure_web_sudo.sh provisions a
narrowly-scoped sudoers rule for it. api_v3.py's install_base_requirements
and install_plugin_requirements actions now use it via `sudo -n`, falling
back to today's current-user-only install (with an explanatory note) if
the wrapper isn't set up yet, so existing installs don't regress.
Also uses --ignore-installed in the wrapper: root's site-packages often has
apt/dpkg-managed copies of common libraries (requests, etc.) with no pip
RECORD file, which pip refuses to upgrade in place and aborts the *entire*
requirements.txt install over — discovered this while testing the fix live,
since a plugin's other already-satisfied-for-the-web-user dependencies had
never actually been attempted as root before.
Also fixes a pre-existing bug in configure_web_sudo.sh where the
display_controller.py/start_display.sh/stop_display.sh sudoers entries used
PROJECT_DIR (scripts/install/, where this script lives) instead of
PROJECT_ROOT (where those files actually live) — visible as the script's
own "File access test" self-check failing. Verified fixed live.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KEZK1P1Q1fu5pcuVrkrCFZ
* fix: invoke safe_pip_install.sh via explicit bash, matching sudoers rule
CodeRabbit caught this on review: the sudoers rule configure_web_sudo.sh
provisions is scoped to "$BASH_PATH $SAFE_PIP_INSTALL_PATH *" (matching
the existing safe_plugin_rm.sh precedent in
src/common/permission_utils.py), but _pip_install_requirements() called
`sudo -n <wrapper> <req_file>` directly, relying on the script's shebang
instead of an explicit bash prefix. sudo matches the literal command line,
so this never matched the allowlisted rule on an install with only the
specific sudoers entries this script provisions — it silently fell back
to the non-root install path every time, which is the exact bug this PR
set out to fix.
This wasn't caught by live testing on ledpi.local because that device
also has a broader, non-standard "NOPASSWD: ALL" grant which masked the
mismatch. Confirmed the fix is correct by reading sudo's documented
command-matching semantics and mirroring the already-proven-working
bash-prefix pattern from permission_utils.py's safe_plugin_rm.sh call
exactly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KEZK1P1Q1fu5pcuVrkrCFZ
* fix: harden safe_pip_install.sh invocation against bash-path drift + address CodeRabbit nitpicks
CodeRabbit follow-up findings on the bash-prefix fix (7558aaab):
1. (Actionable) shutil.which('bash') at runtime could in principle resolve
to a different absolute path than configure_web_sudo.sh's `command -v
bash`, which is resolved once at setup time and baked into the static
sudoers file as a literal string — sudo requires an exact match. Now
tries /usr/bin/bash and /bin/bash (the standard Debian/Raspberry Pi OS
locations, matching what the setup script virtually always produces)
before falling back to this process's own PATH resolution, so a
divergence in just one of them doesn't break the install.
2. (Nitpick) Any nonzero returncode was treated as "sudo denied", so a
real pip failure (bad package, build error) would trigger a pointless
duplicate non-root install attempt and a misleading error message.
Now distinguishes "sudo -n rejected this exact command line" from
"sudo ran it but the command itself failed" via sudo's own diagnostic
text, and surfaces genuine failures immediately without retrying other
bash candidates or falling back.
3. (Nitpick) Added structured logging for every fallback/failure path
(wrapper missing, sudo denied, real install failure), previously only
visible via the returned stdout note — needed for remote debugging on
a headless Pi.
Verified: function-level smoke test confirms a real failure (this sandbox's
system python3 lacking pip) is now correctly classified as non-denial and
returned immediately without retrying candidates or double-installing.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KEZK1P1Q1fu5pcuVrkrCFZ
---------
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Permission Fix Scripts
This directory contains shell scripts for repairing file/directory permissions on a LEDMatrix installation. They're typically only needed when something has gone wrong — for example, after running parts of the install as the wrong user, after a manual file copy that didn't preserve ownership, or after a permissions-related error from the display or web service.
Most of these scripts require sudo since they touch directories
owned by the ledmatrix service user or by root.
Scripts
-
fix_assets_permissions.sh— Fixes ownership and write permissions on theassets/tree so plugins can download and cache team logos, fonts, and other static content. -
fix_cache_permissions.sh— Fixes permissions on every cache directory the project may use (/var/cache/ledmatrix/,~/.cache/ledmatrix/,/opt/ledmatrix/cache/, project-localcache/). Also creates placeholder logo subdirectories used by the sports plugins. -
fix_plugin_permissions.sh— Fixes ownership on the plugins directory so both the root display service and the web service user can read and write plugin files (manifests, configs, requirements installs). -
fix_web_permissions.sh— Fixes permissions on log files, systemd journal access, and the sudoers entries the web interface needs to control the display service. -
fix_nhl_cache.sh— Targeted fix for NHL plugin cache issues (clears the NHL cache and restarts the display service). -
safe_plugin_rm.sh— Validates that a plugin removal path is inside an allowed base directory before deleting it. Used by the web interface (via sudo) when a user clicks Uninstall on a plugin — prevents path-traversal abuse from the web UI.
When to use these
Most users never need to run these directly. The first-time installer
(first_time_install.sh) sets up permissions correctly, and the web
interface manages plugin install/uninstall through the sudoers entries
the installer creates.
Run these scripts only when:
- You see "Permission denied" errors in
journalctl -u ledmatrixor the web UI Logs tab. - You manually copied files into the project directory as the wrong user.
- You restored from a backup that didn't preserve ownership.
- You moved the LEDMatrix directory and need to re-anchor permissions.
Usage
# Run from the project root
sudo ./scripts/fix_perms/fix_cache_permissions.sh
sudo ./scripts/fix_perms/fix_assets_permissions.sh
sudo ./scripts/fix_perms/fix_plugin_permissions.sh
sudo ./scripts/fix_perms/fix_web_permissions.sh
If you're not sure which one you need, run fix_cache_permissions.sh
first — it's the most commonly needed and creates several directories
the other scripts assume exist.