After enabling ssl on postgresql 14, there is error when starting the Postgres server:
2022-05-13 00:09:39.791 CST [938050] FATAL: private key file "/etc/postgresql/14/main/server.key" has group or world access
2022-05-13 00:23:09.163 CST [938097] DETAIL: File must have permissions u=rw (0600) or less if owned by the database user, or permissions u=rw,g=r (0640) or less if owned by root.
What I did is to following the hint above and chmod 640 server.key. Here is the current permission output after chmod (seems only remove r for group)
-rw-r--r-- 1 root root 2727 May 13 00:08 server.crt
-rw-r----- 1 root root 3323 May 13 00:08 server.csr
-rw-r----- 1 root root 1704 May 13 00:08 server.key
But restarting Postgres server still has error:
2022-05-13 00:38:09.331 CST [938235] FATAL: could not load private key file "/etc/postgresql/14/main/server.key": Permission denied
2022-05-13 00:38:09.331 CST [938235] LOG: database system is shut down
pg_ctl: could not start server
What is missing here with the ssl file permission?
First, change the ownership of all files to the PostgreSQL user:
chown postgres server.crt server.key server.csr
Then remove the read permissions for the group from the private key file:
chmod g-r server.key
Related
We have installed postgres v12 on ubuntu 20.04 (with apt install -y postgresql postgresql-contrib) and wish to enable archiving to /data/db/postgres/archive by setting the following in postgresql.conf:
max_wal_senders=2
wal_keep_segments=256
wal_sender_timeout=60s
archive_mode=on
archive_command=cp %p /data/db/postgres/archive/%f
However the postgres service fails to write there:
2022-11-15 15:02:26.212 CET [392860] FATAL: archive command failed with exit code 126
2022-11-15 15:02:26.212 CET [392860] DETAIL: The failed archive command was: archive_command=cp pg_wal/000000010000000000000002 /data/db/postgres/archive/000000010000000000000002
2022-11-15 15:02:26.213 CET [392605] LOG: archiver process (PID 392860) exited with exit code 1
sh: 1: pg_wal/000000010000000000000002: Permission denied
This directory /data/db/postgres/archive/ is owned by the postgres user and when we su postgres we are able to create and delete files without a problem.
Why can the postgresql service (running as postgres) not write to a directory it owns?
Here are the permissions on all the parents of the archive directory:
drwxr-xr-x 2 postgres root 6 Nov 15 14:59 /data/db/postgres/archive
drwxr-xr-x 3 root root 21 Nov 15 14:29 /data/db/postgres
drwxr-xr-x 3 root root 22 Nov 15 14:29 /data/db
drwxr-xr-x 5 root root 44 Nov 15 14:29 /data
2022-11-15 15:02:26.212 CET [392860] DETAIL: The failed archive command was: archive_command=cp pg_wal/000000010000000000000002 /data/db/postgres/archive/000000010000000000000002
So, your archive_command is apparently set to the peculiar string archive_command=cp %p /data/db/postgres/archive/%f.
After the %variables are substituted, the result is passed to the shell. The shell does what it was told, which is to set the (unused) environment variable 'archive_command' to be 'cp', and then tries to execute the file pg_wal/000000010000000000000002, which is not allowed to because it doesn't have the execute bit set.
I don't know how you managed to get such a deformed archive_command, but it didn't come from anything you showed us.
In uWSGI, if I change my socket location to /tmp/api, the website renders. However, if I change the socket address to /srv/www/api/, I get a 502 gateway error.
I believe this is due to a permissions issue regarding the /srv folder and the Nginx/uWSGI users.
In /var/log/nginx/error.log:
*1 connect() to unix:///srv/www/api/app.sock failed (2: No such file or directory) while connecting to upstream, client: xxx.xxx.xxx.xxx, server: api.example.com, request: "GET / HTTP/2.0", upstream: "uwsgi://unix:///srv/www/api/app.sock:", host: "api.example.com"
The Flask project code is located in /srv/www/api. I am logged in as username user.
Permissions:
$ ll -ld /srv/www/api/
drwxrwxr-x 4 www-data www-data 4096 Jun 28 20:52 /srv/www/api/
$ ll -ld /srv/www
drwxrwxr-x 4 username www-data 4096 Jun 27 21:41 /srv/www
$ ll -ld /srv
drwxrwxr-x 4 username username 4096 Jun 27 21:37 /srv
$ ll -ld /tmp
drwxrwxrwt 9 root root 4096 Jun 28 23:05 /tmp
User groups:
$ groups username
username : username sudo dev
$ groups www-data
www-data : www-data dev
$ grep 'dev' /etc/group
dev:x:1001:username,www-data
I have several users setup to be in the dev group. The goal is so that users in the group would be able to read and write to /srv without also being in the root group (is this a bad practice?).
/srv/www/api/app.ini:
[uwsgi]
module = wsgi:app
master = true
processes = 5
socket = /tmp/app.sock
chmod-socket = 660
vacuum = true
die-on-term = true
/etc/nginx/sites/sites-available/api.example.com (location section):
location / {
include uwsgi_params;
uwsgi_pass unix:/tmp/app.sock;
}
Is there a way to fix my permissions setup so that:
The socket would be able to be created in that folder
Users in the dev group without sudo would also be able to read and write the /srv folder and subdirectories
I figured this out. I ended up setting the owners for my folder to:
chown -R username:www-data /srv/www/api
I also made sure to restart the systemctl service after each change. I don't remember doing that earlier so that was very likely the reason why nothing was working even after all the changes made. I only restarted Nginx and not the service itself -- the one responsible for creating the sockets.
To restart the systemctl service:
sudo systemctl restart <service_name>
I have tried a lot but did't get exact knowledge to copy which files to client side
Getting error " Valid authentication certificate required"
Below is postgres DB server directory
total 80
skipping unwanted directory
-rw-------. 1 postgres postgres 1285 Feb 13 20:16 rootCA.crt
-rw-------. 1 postgres postgres 1168 Feb 13 20:16 server.crt
-rw-------. 1 postgres postgres 1679 Feb 13 20:17 server.key
Below is postgresql.conf file content related to SSL configuration.
[postgres#munmvs2951 raj]$ cat postgresql.conf | grep ssl
ssl = on # (change requires restart)
ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL' # allowed SSL ciphers
#ssl_prefer_server_ciphers = on # (change requires restart)
#ssl_ecdh_curve = 'prime256v1' # (change requires restart)
#ssl_renegotiation_limit = 512MB # amount of data between renegotiations
ssl_cert_file = 'server.crt' # (change requires restart)
ssl_key_file = 'server.key' # (change requires restart)
ssl_ca_file = 'rootCA.crt' # (change requires restart)
#ssl_crl_file = '' # (change requires restart)
Below is the pg_hba file.
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local replication postgres trust
#host replication postgres 127.0.0.1/32 trust
#host replication postgres ::1/128 trust
#secure client
hostssl postgres postgres clientip/32 md5 clientcert=1
Below is the client side PostgreSQL user home directory from where psql will connect to server.
[postgres#clinet ~]$ ll
total 32
-rw------- 1 postgres postgres 1168 Feb 15 10:27 client.crt
-rw------- 1 postgres postgres 989 Feb 15 10:27 client.csr
-rw------- 1 postgres postgres 1285 Feb 15 11:47 rootCA.crt
-rw------- 1 postgres postgres 1675 Feb 15 11:47 rootCA.key
-rw------- 1 postgres postgres 17 Feb 15 11:47 rootCA.srl
-rw------- 1 postgres postgres 1168 Feb 15 11:47 server.crt
-rw------- 1 postgres postgres 989 Feb 15 11:47 server.csr
-rw------- 1 postgres postgres 1679 Feb 15 11:47 server.key
[postgres#client ~]$ pwd
/home/postgres
when i going to connect, getting below error.
[postgres#client ~]$ /opt/PostgresPlus/9.4AS/bin/psql -U postgres -p5443 -hserverip
psql.bin: FATAL: connection requires a valid client certificate
FATAL: no pg_hba.conf entry for host "10.80.x.x", user "postgres", database "postgres", SSL off
However, I can access without clientcert=1 in pg_hba file.
Ref:
[postgres#client ~]$ /opt/PostgresPlus/9.4AS/bin/psql -U postgres -p5443 -hserverip
psql.bin (9.4.1.3)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=#
In above successful connection, i think ssl checking only at server side not client side.
but i want to know which files should i copy to PostgreSQL home directory #client side. to check certificate as per clientcert=1
Thanks for your help.
See https://www.postgresql.org/docs/current/libpq-ssl.html
Below is the client side PostgreSQL user home directory from where psql will connect to server
They do not belong in the home directory, they belong in a subdirectory of the home directory named .postgresql. Or in Windows, in a directory named "%APPDATA% \ postgresql". And file rootCA.crt has to be named root.crt, unless you have gone out of your way to change the name/location on the client side configuration, which it doesn't seem you have done (you have changed it on the server side, but that doesn't change it on the client side). And client.crt should be named postgresql.crt and you are missing the key file for it. And the fact that you have a file named rootCA.key in the client's directory is frightening, no one but the CA should have access to that.
I am using PostgreSQL 9.5 on Ubuntu 16.04 LTS.
I receive the below error when I type psql:
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
On checking the logs in /var/log/postgresql/postgresql-9.5-main.log, I see the error as:
2018-11-26 13:17:41 IST [3508-1] FATAL: could not access private key file "/etc/ssl/private/ssl-cert-snakeoil.key": Permission denied
Below are the permissions of the /etc/ssl/private and ssl-cert-snakeoil.key files:
vivek#vivek-ThinkPad-E480:~$ ls -l /etc/ssl
total 36
drwxr-xr-x 2 root root 20480 Nov 22 13:06 certs
-rwxr-xr-x 1 root root 10835 Dec 8 2017 openssl.cnf
drwxr--r-- 2 root ssl-cert 4096 Nov 22 13:06 private
vivek#vivek-ThinkPad-E480:~$ sudo ls -l /etc/ssl/private
total 4
-rw-r----- 1 root ssl-cert 1704 Nov 22 13:06 ssl-cert-snakeoil.key
The postgres user is also added to the group ssl-cert.
vivek#vivek-ThinkPad-E480:~$ getent group ssl-cert
ssl-cert:x:112:postgres
NOTE: I found that there is no server.key present in /var/lib/postgresql/9.5/main.
I also posted this on DBA Stackexchange, but no response as yet.
Can anyone guide me in the right direction in setting permissions?
That can never work, and your server will not be able to start, because the OS user postgres has no permissions to access files in etc/ssl/private.
To allow users in the group ssl-cert to access files in the directory, run
chmod g+x /etc/ssl/private
While you're at it, make sure that /etc/ssl has the required permissions.
To test if everything works, become user postgres and try to read the file.
I have a docker image that runs fine on Debian jessie (with kernel 3.16), and when I moved that image to an Ubuntu host (kernel 3.13), postgresql failed to come up. I've narrowed it down to a difference in behaviour when accessing a certain file, and my only explication for it is the difference in host kernel. I'd like to know if anyone has confirm this to be the problem, or has ideas on a possible different root cause for it.
The following sequence of commands shows the problem. First on the 'good' host:
root#lava-docker:/etc# ls -l /etc/ssl/private/ssl-cert-snakeoil.key
-rw-r----- 1 root ssl-cert 1708 Oct 20 19:31 /etc/ssl/private/ssl-cert-snakeoil.key
root#lava-docker:/etc# su - postgres
postgres#lava-docker:~$ ls -l /etc/ssl/private/ssl-cert-snakeoil.key
-rw-r----- 1 root ssl-cert 1708 Oct 20 19:31 /etc/ssl/private/ssl-cert-snakeoil.key
postgres#lava-docker:~$ ls -ld /etc/ssl/private
drwx--x--- 2 root ssl-cert 4096 Oct 20 19:31 /etc/ssl/private
postgres#lava-docker:~$ id
uid=110(postgres) gid=115(postgres) groups=115(postgres),114(ssl-cert)
now the same sequence on the 'bad' host:
root#lava-docker:/# ls -l /etc/ssl/private/ssl-cert-snakeoil.key
-rw-r----- 1 root ssl-cert 1708 Oct 20 19:31 /etc/ssl/private/ssl-cert-snakeoil.key
root#lava-docker:/# su - postgres
postgres#lava-docker:~$ ls -l /etc/ssl/private/ssl-cert-snakeoil.key
ls: cannot access /etc/ssl/private/ssl-cert-snakeoil.key: Permission denied
postgres#lava-docker:~$ ls -ld /etc/ssl/private
drwx--x--- 2 root ssl-cert 4096 Oct 20 19:31 /etc/ssl/private
postgres#lava-docker:~$ id
uid=110(postgres) gid=115(postgres) groups=115(postgres),114(ssl-cert)
as can be seen, even though the file and directory permissions are identical, as is the user configuration (same docker image after all), on one postgres user can see it, but not on the other.
This directory is not mounted with volume option, it is under aufs control
This might be the aufs issue where the permissions in one Docker layer can't be made less restrictive than those in a lower layer.
https://github.com/moby/moby/issues/1295#issuecomment-269058662
The solution seems to be to not use aufs. Use overlay2 instead.
Alternatively it seems if you have Docker 17.09 or later you can use the --chown flag on ADD/COPY. https://stackoverflow.com/a/44766666/127670