T06 · System Persistence
- Location
scripts/setup-cron.sh:5- Finding
Persistent Scheduled Execution of an External Mutable Script
- Content
View full analysis
> $LOG_DIR/health-check.log 2>&1" EXISTING=$(crontab -l 2>/dev/null | grep -F "scripts/health.py check") if [ -n "$EXISTING" ]; then read -p " 是否要替换它?(y/n): " -n 1 -r echo if [[ $REPLY =~ ^[Yy]$ ]]; then crontab -l 2>/dev/null | grep -v "scripts/health.py check" | crontab - else exit 0 fi fi (crontab -l 2>/dev/null; echo "$CRON_LINE") | crontab - crontab -l | grep -v "^#" cd "$WORKSPACE" && python3 scripts/health.py check ``` ### Technical Analysis The installer changes the invoking user's crontab and schedules the following command to run every 12 hours: ```bash cd "$HOME/.qclaw/workspace-a2a-gateway" && python3 scripts/health.py check ``` This is a cross-session persistence mechanism because the scheduled command survives termination of the installation process and continues executing under the user's account. Periodic health checks are related to the Skill's documented functionality, and the installer is interactive rather than automatically invoked by another reviewed file. Nevertheless, modifying the user's persistent scheduler is more invasive than performing an on-demand health check and should be treated as a separate, explicit opt-in operation. The risk is increased because `scripts/health.py` is not present in the audited project. The cron job therefore points to a separately provisioned, mutable Python file whose implementation and integrity cannot be verified from this package. Any party or compromised component capable of modifying that file after cron installation ...[truncated 2258 chars]- Remediation
View remediation
