Subject: [pgjdbc/pgjdbc] PR #3952: ssl: align key file permission check with libpq

From: "harinath001 (@harinath001)" <[email-masked]>
Date: Wed, 04 Mar 2026 20:35:22 +0000

### Context

pgjdbc currently refuses to connect if a private key file has any group or other permissions —
it strictly requires `0600`. That's a safe default, but it's stricter than what libpq (the
reference PostgreSQL C client) actually enforces.

libpq makes a practical distinction: if the key file is owned by root, it allows group-read
(`0640`). This matters in real deployments where a system administrator owns the certificates
and grants read access to a service account via group membership. With pgjdbc's current behavior,
those setups break — even though `psql` and every other libpq-based client works just fine with
them.

For non-root-owned files, libpq is strict: no group or other access. pgjdbc agrees on that part.
The gap is only for root-owned files, and that's what this PR closes.

The relevant check in libpq's `fe-secure-openssl.c` is:
```c
if (buf.st_uid == 0 ?
    buf.st_mode & (S_IWGRP | S_IXGRP | S_IRWXO) :
    buf.st_mode & (S_IRWXG | S_IRWXO))
```

### Changes to Existing Features:

- The only behavioral change is that root-owned key files with `GROUP_READ` (`0640`) are now
  accepted instead of rejected, matching libpq. All other permission checks remain unchanged.

### All Submissions:

* [x] Have you followed the guidelines in our [Contributing](https://github.com/pgjdbc/pgjdbc/blob/master/CONTRIBUTING.md) document?
* [x] Have you checked to ensure there aren't other open [Pull Requests](../../pulls) for the same update/change?

### New Feature Submissions:

1. [x] Does your submission pass tests?
2. [x] Does `./gradlew styleCheck` pass ?
3. [x] Have you added your new test classes to an existing test suite in alphabetical order?

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Thu, 05 Mar 2026 11:44:19 +0000

I don't see any issues with this. Will merge if no objections

---

From: "harinath001 (@harinath001)" <[email-masked]>
Date: Mon, 09 Mar 2026 18:53:10 +0000

@davecramer yeah, this change will be very helpful in many environments !! Waiting for the merge and release , thank you !!

---

From: "tonirevert (@tonirevert)" <[email-masked]>
Date: Tue, 19 May 2026 08:15:39 +0000

After this change, the certificates that we use in our company started to fail on DBeaver because of the permission checks...