PYSEC-2026-3467 
## Insecure Permission Assignment for Garmin OAuth Token Store

### Summary

`garminconnect` (≤ 0.3.4) wrote its OAuth token store to disk without restricting file-system permissions. Under the default Linux umask (`022`) the token file `garmin_tokens.json` was created world-readable (`0o644`). The file contains the DI **refresh token**, so any other local user on a shared host could read it and obtain persistent, unauthorized access to the victim's Garmin Connect account.

- **Severity:** High
- **Weakness:** CWE-732 (Incorrect Permission Assignment for Critical Resource)
- **Affected versions:** `<= 0.3.4`
- **Patched version:** `0.3.5`

### Details

`Client.dump()` created the token directory and file with no `mode` argument, leaving permissions entirely to the process umask:

```python
def dump(self, path: str) -> None:
    p = Path(path).expanduser()
    if p.is_dir() or not p.name.endswith(".json"):
        p = p / "garmin_tokens.json"
    p.parent.mkdir(parents=True, exist_ok=True)   # no mode=
    p.write_text(self.dumps())                     # no permission restriction
```

The serialized payload includes `di_token`, `di_refresh_token`, and `di_client_id`. The call is in the core library (`Garmin.login(tokenstore=...)` persists tokens this way), and all shipped usage examples default the token store to `~/.garminconnect`.

Under `umask 022` the resulting permissions were:

- token directory → `0o755`
- `garmin_tokens.json` → `0o644` (world-readable)

A separate, unprivileged user on the same machine could read the file with a plain `open()` — no elevated privileges required — and extract the refresh token.

### Impact

Local credential theft / privilege escalation on multi-user Linux or macOS hosts running under a permissive umask. The stolen refresh token can be exchanged for fresh access tokens via Garmin's OAuth endpoint, granting ongoing access to the victim's account (health/fitness data, activity history, device management) until the token is revoked.

### Patch

Fixed in **0.3.5** (commit `77a3837`). `dump()` now creates the directory as `0o700` and writes the token file as `0o600` regardless of umask — using `os.open(..., O_CREAT|O_WRONLY|O_TRUNC, 0o600)` with `O_NOFOLLOW` where available, plus a defensive `chmod` that also tightens a pre-existing loose file:

```python
p.parent.mkdir(mode=0o700, parents=True, exist_ok=True)
with contextlib.suppress(OSError):
    p.parent.chmod(0o700)
flags = os.O_WRONLY | os.O_CREAT | os.O_TRUNC
if hasattr(os, "O_NOFOLLOW"):
    flags |= os.O_NOFOLLOW
fd = os.open(p, flags, 0o600)
with os.fdopen(fd, "w", encoding="utf-8") as f:
    f.write(self.dumps())
with contextlib.suppress(OSError):
    p.chmod(0o600)
```

Verified under `umask 022`: directory `0o700`, file `0o600`, no group/other access.

### Workarounds

If you cannot upgrade immediately, restrict the token store manually and keep it owner-only:

```bash
chmod 700 ~/.garminconnect
chmod 600 ~/.garminconnect/garmin_tokens.json
```

### Remediation

1. **Upgrade** to `garminconnect >= 0.3.5`:
   ```bash
   pip install --upgrade garminconnect
   ```
2. **Fix any token file already on disk** — upgrading only tightens permissions
   on the *next* write, so an existing world-readable file stays exposed until
   then:
   ```bash
   chmod 600 ~/.garminconnect/garmin_tokens.json
   # or remove it and log in again to mint a fresh token store
   ```
3. **If the file was exposed on a shared host, treat the refresh token as
   compromised.** Re-authenticate (delete the token store and log in again) so
   a new token is issued; consider the previously stored token potentially
   read by others until rotated.

### Credit

Reported by **EQSTLab** via a private security advisory. garminconnect thanks them for the detailed, responsible disclosure.
CVSS v3.1 score: 8.4