No way to override - Error: pq: Private key file has group or world access. Permissions should be u=rw (0600) or less

I found while using Windows Subsystem for Linux, that when I tried using the Linux binary of cockroachdb, libpq didn't like my certificate files because the permissions are 777.

There should be a way to override this check for people that just want to use libpq in a test environment where permissions don't matter. I have to keep the files on the Windows partition where there are no unix based permissions so I have direct access to my files with IDEs and such.

This could also be problematic for users trying to utilize storage systems from Linux that don't use unix-like permissions, where everything presents as 777 or some arbitrary perm value.

The cockroachdb commands had an elegant solution of reading the environment variable COCKROACH_SKIP_KEY_PERMISSION_CHECK to bypass it's check:
https://github.com/cockroachdb/cockroach/blob/master/pkg/security/certificate_loader.go#L33-L41

Maybe something like this could be a viable option for libpq?

[cbandy]

Could we remove this build flag and instead check runtime.GOOS == "windows"?
https://golang.org/pkg/runtime/#pkg-constants

pq/ssl_permissions.go

Line 1 in 9eb73ef

// +build !windows

I think that would be logical to do and slap in a check for an environment variable instead that a user can modify.

[singron]

This also blocks use of keys that are intentionally readable by a group.

[theonewolf]

@singron we hit this exact issue when trying to use a PostgreSQL backend with certificate-based authentication within Kubernetes.

Reference issues that this causes:

• https://github.com/banzaicloud/bank-vaults/issues/777
• Volumes are created in container with root ownership and strict permissions kubernetes/kubernetes#2630

Ideally, we'd have an easy method within Kubernetes of setting the user and mode bits precisely on mounted files, but that currently doesn't exist.

We can get the group set canonically, but there is then no way to override this check within lib/pq.

[mikroskeem]

Any updates on this?

[whyman]

Any update on this?

[SteveVaknin]

Updates?

[tisc0]

The cockroachdb commands had an elegant solution of reading the environment variable COCKROACH_SKIP_KEY_PERMISSION_CHECK to bypass it's check:
https://github.com/cockroachdb/cockroach/blob/master/pkg/security/certificate_loader.go#L33-L41

Maybe something like this could be a viable option for libpq?

HI, and thanks for bringing this issue up, but I'd say a security workaround is less elegant than weak.

This isn't a security workaround, it's telling PQ to knock it off with validating the SSL chain. This is normal behavior in dev environments. The encryption still happens. It's the same ciphers as previously. It's just making it so you can use self-signed certs for testing. Managing your own CA and installing your own root certs is literally done by no one in their right mind anywhere in lower environments.

haha I just reported exactly the same issue on the cockroachdb tracker - cockroachdb/cockroach#61975

0640 is a totally acceptable permission (25 years of Linux/Unix here).

The reason you might want 0640 permission is so that you could add a number of users to the same group (cockroachdb) duplicating the files loads of times just so you can set 0600 permission is not idiomatic in the Unix world.

[cbandy]

https://www.postgresql.org/docs/current/libpq-ssl.html#LIBPQ-SSL-CLIENTCERT

The private key file must not allow any access to world or group; achieve this by the command chmod 0600

https://www.postgresql.org/docs/current/libpq-ssl.html#LIBPQ-SSL-CLIENTCERT

The private key file must not allow any access to world or group; achieve this by the command chmod 0600

@cbandy why should the private key not be accessible to the specified group?

[cbandy]

There are discussions out there for which one can search. Here's one that mentions macOS groups like "staff".

https://www.postgresql.org/message-id/20160218133438.GC15260@msg.df7cb.de