IMGIITRoorkee / IMGIITRoorkee/chakra-docker
Database dumps are written unencrypted to an S3 mount that is also mounted on the public server
Nobody has claimed this yet.
- Dominant language
- HTML
- Stars
- 1
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
`postgres.sh:6` sources the live DB credentials into the script environment, then `:14-15` writes **two** plaintext `pg_dump` files into the S3 FUSE mount. There is **no `gpg`, no `openssl enc`, no `age`** anywhere in the pipeline.
A `pg_dump` of this database contains every `ChakraUser` record, all `django_celery_results` task arguments in cleartext, and all confman state.
**Who can read it:** anyone with filesystem access on root1 *or* **root2** — the same bucket is mounted on both, and root2 is the internet-facing static server. If s3fs is mounted with `allow_other` or default permissions, every local user on root2 can read the full database dump. root2 has no need for that bucket at all.
Compounding bugs in the same scripts: the quoted-glob prune means dumps accumulate indefinitely, `DAYS_TO_KEEP=14` is defined and **read by nothing**, and `script.sh:19-21` interpolates config values into a command unquoted.
**Fix:** pipe `pg_dump` through `gpg --encrypt` or `age` before it touches the mount; verify bucket SSE-KMS and a policy denying public and cross-account reads; verify the s3fs mount has `allow_other` **off** and mode 0700; **stop mounting the backup bucket on root2**.
---
**Evidence**
```
chakrabackup-script/backup_script/postgres.sh:6,14-18; config.yml:4; configs/zip_config.env:4-5
```
- Verified against: `origin/master 44ca47e (2026-07-25)`
- Verdict: **CONFIRMED**
- Reachable: Anyone with filesystem access on either server.
- Preconditions: UNVERIFIED: bucket encryption, bucket policy, and s3fs mount options. Commands in the report.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read chakrabackup-script/backup_script/postgres.sh, script.sh, config.yml, and configs/zip_config.env, starting with the referenced lines and the current deployment configuration. Confirm the backup pipeline, retention and quoting behavior, then verify encryption, bucket policy, mount permissions, and removal of the backup mount from root2; done means plaintext dumps are never written and the exposed storage path is eliminated.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, postgresql, shell
- Domain
- cloud, databases, infrastructure, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100