kdevtmpfsi process consuming cpu on postgres:13 image

[DmitriyStoyanov]

From some time, we faced with 100% cpu usage on server with posgres:13 image used, it goes from this process
in top we have:
29153 999 20 0 515548 264328 0 S 92.4 52.9 3:25.10 kdevtmpfsi

it comes from postgres process:
ps -ef|grep 29153
999 29153 28324 97 10:20 ? 00:08:15 /tmp/kdevtmpfsi

ps -ef|grep 28324
999 28324 28307 0 10:09 ? 00:00:00 postgres

Looks like the same issue as redis redis/docker-library-redis#217
also described here https://stackoverflow.com/questions/60151640/kdevtmpfsi-using-the-entire-cpu

[DmitriyStoyanov]

Faced with such attack with default password on db

[tianon]

Indeed - as you've noted, this is an unfortunate consequence of having a public-facing instance with a compromised (or simple) password. 😞

However, our image doesn't actually have a default password, and in #658 we changed to explicitly require users of the image to set a password:

postgres/docker-entrypoint.sh

Lines 112 to 120 in 3884130

	Error: Database is uninitialized and superuser password is not specified.
	You must specify POSTGRES_PASSWORD to a non-empty value for the
	superuser. For example, "-e POSTGRES_PASSWORD=password" on "docker run".
	You may also use "POSTGRES_HOST_AUTH_METHOD=trust" to allow all
	connections without a password. This is *not* recommended.
	See PostgreSQL documentation about "trust":
	https://www.postgresql.org/docs/current/auth-trust.html

The most effective mitigations I would recommend are choosing a strong (random!) password and not exposing the database publicly -- with containers, you should be able to have containers that need access to the database connect to it directly via container networking without exposing the ports, which increases the security dramatically.

[DmitriyStoyanov]

Thank you, our instance fixed by changing default password

[fresonn]

Thanks! It saved my time 👍