Check if schema already exists before create extension [BF-2375]

[0xlianhu]

BF-2375

Security bug - privilege escalation

[rdunklau]

Since we are using aiven_extras schema everywhere in the extension code, it makes sense not to check for @extschema@ but for aiven_extras directly.

Things could also be unified the other way, using @extschema@ everywhere.

As for the privileges escalation, is this enough ? Not sure how, but we could end up in a situation where the schema is rightfully owned by the correct user, but some default privileges have been added.

I'm not sure what the implication of this is, but could we instead:

• remove the schema from the control file, that way it is not created by postgres for us
• explicitly create the aiven_extras schema in the extension itself. That way it will also be dropped when we drop the extension.

That way we are sure the schema is created afresh, and if it already exists we fail.
This may require a bit more work for the upgrade scripts, which currently are supposed to be idempotent.

[0xlianhu]

Since we are using aiven_extras schema everywhere in the extension code, it makes sense not to check for @extschema@ but for aiven_extras directly.

Things could also be unified the other way, using @extschema@ everywhere.

As for the privileges escalation, is this enough ? Not sure how, but we could end up in a situation where the schema is rightfully owned by the correct user, but some default privileges have been added.

I'm not sure what the implication of this is, but could we instead:

• remove the schema from the control file, that way it is not created by postgres for us
• explicitly create the aiven_extras schema in the extension itself. That way it will also be dropped when we drop the extension.

That way we are sure the schema is created afresh, and if it already exists we fail. This may require a bit more work for the upgrade scripts, which currently are supposed to be idempotent.

1. I can use the hard-code aiven_extras schema name instead of @extschema@, less changed lines.
2. Not sure how, but we could end up in a situation where the schema is rightfully owned by the correct user, but some default privileges have been added. This exploitation is to utilize the vulnerability when the schema is owned by an unprivileged user before creating an extension. If the schema is rightfully owned by the correct user (e.g., postgres) before creating an extension. Then not a problem, because the unprivileged user would not be able to alter schema aiven_extras, which would not be able to exploit the vulnerability.
3. Will try if can explicitly create the schema in SQL instead of using postgres to create it. But we don't have a specific upgrade script, just re-create everything, what do you mean by a bit more work for the upgrade scripts here?

[rdunklau]

Will try if can explicitly create the schema in SQL instead of using postgres to create it. But we don't have a specific upgrade script, just re-create everything, what do you mean by a bit more work for the upgrade scripts here?

What I mean is that instead of doing a cp of the raw aiven-extras file to generate the upgrade script, we should pipe it through sed to delete the CREATE SCHEMA statement.

[0xlianhu]

Will try if can explicitly create the schema in SQL instead of using postgres to create it. But we don't have a specific upgrade script, just re-create everything, what do you mean by a bit more work for the upgrade scripts here?

What I mean is that instead of doing a cp of the raw aiven-extras file to generate the upgrade script, we should pipe it through sed to delete the CREATE SCHEMA statement.

Yes. Maybe this time only fix the bug instead, and keep the existing schema creation as it is?

[0xlianhu]

Will try if can explicitly create the schema in SQL instead of using postgres to create it. But we don't have a specific upgrade script, just re-create everything, what do you mean by a bit more work for the upgrade scripts here?

What I mean is that instead of doing a cp of the raw aiven-extras file to generate the upgrade script, we should pipe it through sed to delete the CREATE SCHEMA statement.

This might be more complicated to make the upgrade idempotent.

The creation script file (e.g., aiven_extras--<current_version>.sql) can be omitted if we have an upgrade path to the current version according to https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSIONS-UPDATE-SCRIPTS

This means we may also need the schema to be created in an update script.