IMGIITRoorkee / IMGIITRoorkee/chakra-docker

Database dumps are written unencrypted to an S3 mount that is also mounted on the public server

Open
#41 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

audit effort:M security sev:high
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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.