T06 · System Persistence
- Location
scripts/install_cron.sh:13- Finding
Persistent Scheduled Tasks Installed in the User Crontab
- Content
View full analysis
> run.log 2>&1" # 2. Weekly Hot Pool Update (Monday 08:30) JOB2="30 08 * * 1 cd $WORK_DIR && ./update_hot.sh >> pool_update.log 2>&1" # Backup existing cron crontab -l > mycron.bak 2>/dev/null # Create new cron file from existing (excluding old quant jobs to avoid duplicates) grep -v "quant_engine" mycron.bak > "$CRON_FILE" 2>/dev/null || true # Append new jobs echo "# --- Hangzhou AI Quant Engine ---" >> "$CRON_FILE" echo "$JOB1" >> "$CRON_FILE" echo "$JOB2" >> "$CRON_FILE" echo "" >> "$CRON_FILE" # Newline # Install crontab "$CRON_FILE" echo "✅ Crontab installed successfully:" crontab -l | grep "quant_engine" rm "$CRON_FILE" ``` ### Technical Analysis The installer modifies the invoking user's crontab and creates two jobs that survive the current Skill execution. Scheduled analysis is documented as an optional feature, so cron use is related to the declared functionality. However, it grants the Skill persistent execution and therefore requires stronger safeguards than an ordinary one-time analysis run. The target directory is derived from the caller's current working directory rather than from the installer's own location: ```bash WORK_DIR="$(pwd)/workspace/quant_engine" ``` The installer does not validate that `run_task.sh` or `update_hot.sh` is a trusted regular file. The project contains no `update_hot.sh`; its actual updater is named `update_pool_hot.py`. Consequently, a later-created executable at the scheduled path could be run automatically. The script also copies the comp ...[truncated 1245 chars]- Remediation
View remediation
