cb055b4b1f
dockerDeleteData (uninstall) and the wipe-before-restore step in
restoreAppStart both did `runFileOp rm -rf $containers_dir$app_name`,
which runs as $CFG_DOCKER_INSTALL_USER (dockerinstall, uid 1002 on
rootless). That user owns app-template files but CANNOT remove
container sub-UID dirs created by the daemon's userns mapping —
postgres data at uid 232070, nextcloud html at uid 33, etc. The rm
therefore silently failed with
rm: cannot remove '/libreportal-containers/invidious/postgresdata':
Permission denied
while still reporting "<app> successfully uninstalled" — leaving the
sub-UID directory tree on disk to confuse the next install and leak
storage.
Fix: route the wipe through a new `app-data-remove` action in the
root-owned libreportal-ownership helper. Root can rm sub-UID files
unconditionally. The helper validates the app name (alphanumeric +
. _ -, no traversal), refuses the WebUI's own slot (libreportal), and
is idempotent when the dir is already gone.
Two callers updated:
- scripts/docker/app/uninstall/delete_data.sh
- scripts/restore/restore_app_start.sh
The helper itself ships root-owned at /usr/local/lib/libreportal/, so a
fresh install or release upgrade is needed to pick up the new action.
Bumped init.sh footprint_version 2 → 3 so the runtime updater
prompts a root re-install on the next release.
Signed-off-by: librelad <librelad@digitalangels.vip>
18 lines
582 B
Bash
Executable File
18 lines
582 B
Bash
Executable File
#!/bin/bash
|
|
|
|
dockerDeleteData()
|
|
{
|
|
local app_name="$1"
|
|
|
|
if [[ "$app_name" == "" ]]; then
|
|
isError "No app_name provided, unable to continue..."
|
|
else
|
|
# Runs via the root-owned helper instead of runFileOp (= dockerinstall),
|
|
# so container sub-UID dirs (postgres uid 232070, www-data uid 33, …)
|
|
# are wiped instead of left behind with a "Permission denied" error
|
|
# and a misleading "successfully uninstalled" message.
|
|
runOwnership app-data-remove "$app_name"
|
|
checkSuccess "Deleting $app_name install folder"
|
|
fi
|
|
|
|
} |