Security checklist: DB "operations needed"

[adriendupuis]

Question	Answer
JIRA Ticket	N/A
Versions	4.x!, 3.3?, 2.5?
Edition	All

How do I "Ensure that the database user used by the web app only has access to do the operations needed"?

Forked from #2355

Checklist

• Text renders correctly
• Text has been checked with vale
• Description metadata is up to date
• Redirects cover removed/moved pages
• Code samples are working
• PHP code samples have been fixed with PHP CS fixer
• Added link to this PR in relevant JIRA ticket or code PR

[glye]

Won't we need TCL commands here, too? BEGIN START TRANSACTION, COMMIT, ROLLBACK, SET at least?

[adriendupuis]

I may have misinterpreted your remark at first. I thought it was about wrapping the commands in a transaction batch.

SET could be added in PostgreSQL: https://www.postgresql.org/docs/current/sql-grant.html#SQL-GRANT-DESCRIPTION-OBJECTS

I see no equivalent on MySQL: https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html

[adriendupuis]

Suggested change

	CREATE USER 'user'@'host' IDENTIFIED BY 'password';
	GRANT SELECT, INSERT, UPDATE, DELETE ON database_name.* TO 'user'@'host';
	START TRANSACTION;
	CREATE USER 'user'@'host' IDENTIFIED BY 'password';
	GRANT SELECT, INSERT, UPDATE, DELETE ON database_name.* TO 'user'@'host';
	COMMIT;

[adriendupuis]

Suggested change

	CREATE USER user PASSWORD 'password';
	GRANT CONNECT ON DATABASE database_name TO user;
	GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO user;
	ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO user;
	BEGIN;
	CREATE USER user PASSWORD 'password';
	GRANT CONNECT ON DATABASE database_name TO user;
	GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO user;
	ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO user;
	COMMIT;

[adriendupuis]

Suggested change

	CREATE USER user PASSWORD 'password';
	GRANT CONNECT ON DATABASE database_name TO user;
	GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO user;
	ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO user;
	CREATE USER user PASSWORD 'password';
	GRANT CONNECT ON DATABASE database_name TO user;
	GRANT SET, SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO user;
	ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO user;

[glye]

I'll have a looksie again soon. As I recall, there was debate if it even makes sense to recommend this. Which is a fair point. Sabotage is perfectly possible with just INSERT and UPDATE, and read access with SELECT is often the most dangerous of all.

[glye]

Sorry I haven't followed up on this. I am doubting now if we should have this section on the checklist at all. If an attacker has reached the point where they can run arbitrary SQL commands, they can extract, insert, modify and delete information anyway, and blocking schema changes does very little to remove harm. But it could make upgrades more difficult if people get their setup wrong. I am leaning towards removing the entire section.

[adriendupuis]

I am doubting now if we should have this section on the checklist at all. […] I am leaning towards removing the entire section.

@glye Yes, if we can't answer the question raised by this note (partially because it would be too late anyway), we should remove the note itself.

[adriendupuis]

#2565 will probably solve the problem in another way.