unzip -tq on a password-protected archive tries to open /dev/tty to
prompt for the password. Inside a tmux session this generates SIGTTIN,
which stops the process (ps state T). A stopped process cannot receive
SIGTERM, so timeout waited indefinitely for a child that would never exit.
Fix: wrap all unzip calls with setsid so the process runs in a new
session without a controlling terminal. The /dev/tty open then fails
immediately with ENXIO and unzip exits with a non-zero code instead of
blocking. Additional hardening:
- timeout -k 5: send SIGKILL 5 s after SIGTERM as a last resort
- < /dev/null: also cut off stdin as a secondary safeguard
- exit 137 (128+9, SIGKILL) treated as timeout alongside 124
- error output matching "password"/"encrypt"/"need PK compat" reported
as UNVERIFIED instead of INVALID
Affects: recover_bad_signature.sh, restore_bad_signature.sh,
recreate_bad_signature.sh
unzip -tq can block indefinitely on very large or partially corrupt
ZIP archives (stalls in I/O rather than exiting with a CRC error).
All three scripts that call validate_recovered_file() are affected:
recover_, restore_, recreate_bad_signature.sh.
Both the quick check (unzip -tq) and the verbose error pass (unzip -t)
are now wrapped with `timeout 120`. Exit code 124 (timed out) is
reported as UNVERIFIED with a hint for manual follow-up; any other
non-zero exit is still reported as INVALID with the first error line.
Betroffen: scan_, recover_, restore_, recreate_bad_signature.sh
und diagnose_share_key.sh
Bei Accounts mit sehr vielen bzw. sehr großen Dateien konnte der
jeweilige Pro-Account-Durchlauf länger als eine Stunde dauern und
wurde dann von PHP mit "Maximum execution time of 3600 seconds
exceeded" abgebrochen - mitten im Lauf, ohne jedes Ergebnis.
- su -c "$PHP_BIN ..." ruft PHP jetzt zusätzlich mit
-d max_execution_time=0 auf.
- Das allein reicht nicht: Nextclouds eigenes lib/base.php setzt
beim Bootstrap unbedingt (fest einprogrammiert, nicht
konfigurierbar) set_time_limit(3600) und überschreibt damit den
CLI-Flag wieder. Daher zusätzlich direkt nach dem require von
lib/base.php ein erneutes set_time_limit(0) in jedem der fünf
eingebetteten PHP-Scripte, das Nextclouds Reset seinerseits
rückgängig macht.
Kein Verhaltensunterschied für kleine/normale Accounts, betrifft
nur die maximale Laufzeit pro Account.
chris