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

[ghost]

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

[ghost]

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.

[ghost]

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.

[ghost]

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

[ghost]

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

[grassbd]

it would be importand for container based postgres clients to have an option to ignore this error (or simply display the warning,but don't stop working). i understand the security aspects of this error, but it prevents users from using postgres in a container based environment.

Whats users are doing in container based environments is to copy the file in a second place and give them the correct rights. this is less security because the file now exists two times and the original file has stil group readable access.

[binarytemple]

Hey, this seems to have been fixed in master, thank goodness! 🥳

d8917fa
https://github.com/lib/pq/blob/master/ssl_permissions.go#L1-L93

[grassbd]

Hey, nice to hear. thank you
I was wondering why the ticket is still open, and so i haven't had a looked at the linked pull request.
as i can see the it is merged into version v1.10.6.

[ghost]

It's open because I've not been keeping track of this issue. Looks like perms checking can be skipped now as mentioned, closing.