-
-
Notifications
You must be signed in to change notification settings - Fork 277
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MBS-11962: Update privileges for all database users on schema changes #3243
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea seems great. Can we add a test for the script, please? :)
Tests seem to be failing |
Seems to be because the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTMBDNT
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I created the roles musicbrainz_ro
, caa_redirect
and sir
using admin/psql
then ran the new script and obtained the following error message:
`LINE 3: WITH INHERIT TRUE;`
Failed query:
'GRANT "musicbrainz_ro"
TO "caa_redirect"
WITH INHERIT TRUE;
'
()
42601 DBD::Pg::st execute failed: ERROR: syntax error at or near "INHERIT"
LINE 3: WITH INHERIT TRUE;
^ [for Statement "GRANT "musicbrainz_ro"
TO "caa_redirect"
WITH INHERIT TRUE;
"]
at /musicbrainz-server/admin/../lib/Sql.pm line 123.
Sql::catch {...} (MusicBrainz::Server::Exceptions::DatabaseError=HASH(0x5acb49453658)) called at /musicbrainz-server/perl_modules/lib/perl5/Try/Tiny.pm line 123
Try::Tiny::try(CODE(0x5acb49453dd8), Try::Tiny::Catch=REF(0x5acb49353978)) called at /musicbrainz-server/admin/../lib/Sql.pm line 124
Sql::do(Sql=HASH(0x5acb48ebf288), "GRANT \"musicbrainz_ro\"\x{a} TO \"caa_redirect\"\x{a} WITH INHERIT TRUE;\x{a}") called at ./admin/UpdateDatabasePrivileges.pl line 119
Edit: I just realized from your above comment that PG 16 is required here. I can’t test it at the moment, but my other comments probably still stand.
@yvanzo I think I've addressed all of your comments (and it should also work on PG<16 now). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
💯 agreed that WITH INHERIT
is better set once for all for roles. The other new syntax in PG 16 is probably for more casual use case.
I made a couple of (also minor) ready-to-pick suggestions for improving the output.
Last, when running this script (without --nogrant
) two times in a row, two additional lines are logged:
NOTICE: role "caa_redirect" is already a member of role "musicbrainz_ro"
NOTICE: role "sir" is already a member of role "musicbrainz_ro"
This doesn’t seem to be an issue, mentioning it just in case.
Adds a new script, admin/UpdateDatabasePrivileges.pl, which is invoked from upgrade.sh and updates privileges for the following users if they exist: * `musicbrainz_ro` * `caa_redirect` * `sir` The script works by revoking all write privileges from `musicbrainz_ro`, and then granting `USAGE` on all schemas, and `SELECT` privileges on all tables in those schemas. Next, for the last two schemas, it revokes all privileges from them (including `SELECT` and `USAGE`), and then simply grants them membership in the `musicbrainz_ro` role.
Thanks!
Yeah, those are logged by PG if you try to grant a privilege that already exists. It's harmless though and may be useful information (if it wasn't expected for them to exist). |
Problem
MBS-11962
When new tables or schemas are added, production database users like
musicbrainz_ro
may not be granted access to them.Solution
Adds a new script, admin/UpdateDatabasePrivileges.pl, which is invoked from upgrade.sh and updates privileges for the following users if they exist:
musicbrainz_ro
caa_redirect
sir
The script works by revoking all write privileges from
musicbrainz_ro
, and then grantingUSAGE
on all schemas, andSELECT
privileges on all tables in those schemas.Next, for the last two schemas, it revokes all privileges from them (including
SELECT
andUSAGE
), and then simply grants them membership in themusicbrainz_ro
role.Testing
I added the three roles in question to my local database and ran admin/UpdateDatabasePrivileges.pl. I observed that each of the three users could
SELECT
from any table in our schemas, but not modify them.