Project

General

Profile

Actions
Copy link

Bug #2770

closed

System binaries (7z, du, df) called without absolute paths, causing silent failures when PATH is restricted

Added by Jonathan Sandkühler 7 days ago. Updated 6 days ago.

Status:
Closed
Priority:
Normal
Assignee:
Bernhard Koschiček-Krombholz
Category:
Backend
Target version:
9.2.0
Start date:
2026-04-07
Estimated time:
Found in version:
9.1.1

Description

Description
Several places in the codebase call system binaries by name only (e.g. `7z`,
`du`, `df`) via `subprocess`. This works on developer machines but breaks in
any deployment where the process PATH doesn't include standard system
directories — which is the case for systemd services with a custom
`Environment="PATH=..."` line, and for subprocesses that inherit a stripped env.

This causes the two failures:

1. `database_upgrade.py` aborts with "Database backup failed"
In `openatlas/models/export.py`, `sql_export()` calls `pg_dump` then `7z` in
a single `try/except Exception: return False` block. On systems without `7z`
(`p7zip-full` on Debian, not listed at all for RPM-based distros), the
`FileNotFoundError` is silently swallowed. The script aborts — even though
`pg_dump` succeeded and a valid `.sql` file was written to `SQL_PATH`.

2. `/admin` returns 502 Bad Gateway
In `openatlas/views/admin.py`, `get_disk_space_info()` calls `du` and `df`
via `subprocess.run()`. Under a systemd service with
`Environment="PATH=/var/www/openatlas/venv/bin"`, neither binary is found,
raising `FileNotFoundError` and crashing the request.

Steps to reproduce

Bug 1:
1. Deploy on a system without p7zip (RHEL/AlmaLinux/Rocky, or Debian without
p7zip-full)
2. Run: `python3 install/upgrade/database_upgrade.py`
3. Observe: "Database backup failed." — script aborts, database not upgraded

Bug 2:
1. Run the OpenAtlas systemd service with a restricted PATH (any non-Debian
setup following the official service file template)
2. Log in and navigate to `/admin`
3. Observe: 502 Bad Gateway; gunicorn log shows
`FileNotFoundError: [Errno 2] No such file or directory: 'du'`

Expected behaviour
- Clear error identifying the missing binary, or
- Pre-flight check at startup/before backup that validates all required
binaries with an actionable message, or
- Use `shutil.which('7z')` / absolute paths so failures are explicit

Affected files
- `openatlas/models/export.py` — `7z` (and `pg_dump`) called by name only
- `openatlas/views/admin.py` — `du` and `df` called by name only

Environment
- OS: RHEL 9 (systemd service with restricted PATH)
- OpenAtlas: 9.1.1
- `p7zip` not available in default RHEL repos (requires EPEL)

Actions
Copy link
 #1

Updated by Bernhard Koschiček-Krombholz 7 days ago

  • Category set to Backend
  • Status changed from New to Acknowledged
  • Assignee set to Bernhard Koschiček-Krombholz
  • Target version set to 9.2.0
  • Found in version changed from 9.0.0 to 9.1.0
Actions
Copy link
 #2

Updated by Bernhard Koschiček-Krombholz 6 days ago

  • Status changed from Acknowledged to Closed
  • Found in version changed from 9.1.0 to 9.1.1

Thanks a lot for the detailed report and for bringing this to our attention!

While our default environment is Debian 13, we take these best practices seriously. I have audited all subprocess calls and applied the following fixes:

  • Dynamic Paths: All binaries are now resolved dynamically at runtime (no more hardcoded names), this should fix issues with restricted systemd $PATH environments.
  • For non-critical tasks like compression of SQL backups, the system now uses fallbacks (e.g., keeping uncompressed files) instead of aborting.
  • Failures are now explicitly logged with full stderr output (Admin -> General -> System log or just add /log to the base URL) and flashed via the UI to make debugging much easier.

Changes are now implemented in develop.

I hope this will fix all your problems.

Actions
Copy link

Also available in: Atom PDF