If mkdir(queue.lock) failed for a reason other than "already exists"
(e.g. a permissions or disk problem on the data directory), is_dir()
was false, so the loop `continue`d before ever reaching the tries>=40
retry-limit check or the usleep(), spinning at full CPU forever
instead of failing with a clear error.
Move the staleness check inside an is_dir() guard instead of using
continue to skip past the retry-limit logic, so the bounded-retry
behavior applies regardless of why mkdir failed.
The mkdir-based worker lock had no staleness detection at all, unlike
BackupQueueService::withQueueLock()'s 120s override for its own queue
lock. If the root cron-driven worker was ever killed ungracefully (OOM,
kill -9, reboot mid-job), the lock directory was left behind forever -
every subsequent cron tick would silently exit without processing any
job, so backups/restores would queue forever with no visible error.
Track the owning PID inside the lock directory and reclaim the lock
when that PID is no longer running, or when the lock has no PID file
and is older than WORKER_LOCK_STALE_SECONDS (default 300s). Log to
stderr on both the "held by a live worker" and "reclaiming stale lock"
paths instead of exiting silently either way. cleanup() now uses rm -rf
since the lock directory holds a pid file, not just an empty marker.
stageRestoreUploadFromDirectAdminTemp() accepted the raw
source_file_upload POST value as a literal filesystem path with only
an is_file() check - no ownership or allowed-root validation, unlike
the sibling queueRestoreFromFilePath(). isAllowedSqlFile() only checks
the attacker-controlled display filename, never the real source path.
Since the whole plugin runs as root, any authenticated DirectAdmin user
could stage and restore-import any file readable by root on the
server (e.g. other users' alt-mysql.conf credentials), leaking its
contents via MySQL import error output or the resulting database.
Remove the unsafe raw-path candidate entirely; only accept files whose
basename matches one inside the already-safe, fixed set of known
DirectAdmin/system temp directories.
Specs and plans under docs/superpowers/ are agentic-workflow artifacts,
not plugin runtime files - keep them out of the shipped tarball the
same way tests/ already is.
da_login.php now stores the ticket's restrict_db into
DA_MYSQL_PHPMYADMIN_RESTRICT_DB, and config.inc.php's only_db builder
reads that key instead of the landing-page db field, so an
all-databases login (empty restrict_db) leaves phpMyAdmin unrestricted.
The top-nav PHPMYADMIN button intentionally omits adminer_db to request
access to every database. determineGrantTargets() and the ticket's new
restrict_db field now distinguish that case from a specific per-row
database request instead of collapsing both into single-database scope.
After live testing on the real server, three follow-up issues surfaced:
- PhpMyAdminSso granted the temporary SSO MySQL role access to every
database the account owns, not just the one the "Zaloguj do bazy"
button was clicked for, so phpMyAdmin showed all databases. Extract
determineGrantTargets() and scope the GRANT to only the requested
database; also set phpMyAdmin's only_db from the SSO session so the
UI itself only shows that database.
- phpMyAdmin's LogoutURL pointed at da_login.php with no ticket, which
always produced "Missing or invalid phpMyAdmin login ticket." on
logout. Add a DIRECTADMIN_PANEL_PORT setting (default 2222) and
point LogoutURL at the plugin's own database list
(/CMD_PLUGINS/alt-mysql/index.html) instead.
- The create-database form kept echoing back the just-submitted
values after a successful creation, forcing manual clearing before
creating the next database. Clear the relevant $_POST keys once
creation succeeds so the form resets while still preserving sticky
values on validation failure.
Bump version to 1.2.14 and rebuild the release archive.
Live testing on a real DirectAdmin/CustomBuild server showed the Apache
alias fix alone wasn't enough: the default vhost serving /var/www/html
uses `SuexecUserGroup webapps webapps`, so PHP for the private phpMyAdmin
copy actually executes as user/group "webapps" - not as Apache's own
httpd.conf "Group" (typically "apache"), which is what
detect_apache_group() was reading. SSO ticket files ended up owned
root:apache with mode 0640, unreadable by the webapps-executing
da_login.php, producing "The phpMyAdmin login ticket is not available
or has already been used." even though the ticket really was written.
detect_apache_group() now checks the default vhost's SuexecUserGroup
directive first (the actual PHP-execution identity under SuExec), and
only falls back to the plain Apache Group directive when no
SuexecUserGroup is configured.
Bump version to 1.2.13 and rebuild the release archive.
phpMyAdmin login was broken because phpmyadmin_install.sh never wired
the private phpMyAdmin copy into the web server: no Apache Alias was
registered via DirectAdmin CustomBuild, so the SSO redirect target was
unreachable. Add configure_apache_alias()/apply_apache_alias() (Alias +
Directory blocks, ./build rewrite_confs, httpd reload), detect the real
Apache group instead of hardcoding diradmin:diradmin, stop silently
swallowing chown/chmod failures, and verify an optional SHA256 for the
downloaded phpMyAdmin tarball. Extend phpmyadmin_health_check.sh to
detect a missing/incorrect Apache alias and to probe HTTP reachability.
Security hardening: scope temporary phpMyAdmin SSO MySQL roles to
127.0.0.1 instead of '%', tighten SSO ticket file permissions to 0640
(they contain a plaintext MySQL password), and log MySQL connection
failures for diagnosis instead of swallowing them silently.
Bump version to 1.2.12 and rebuild the release archive.
Marek Miklewicz