Re: Extension security improvement: Add support for extensions with an owned schema
От | Jelte Fennema-Nio |
---|---|
Тема | Re: Extension security improvement: Add support for extensions with an owned schema |
Дата | |
Msg-id | CAGECzQTe3y6xwP9aMbFBCxKnQEEn3G3=cEDqoD5xaOwPwypd_A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Extension security improvement: Add support for extensions with an owned schema (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Extension security improvement: Add support for extensions with an owned schema
|
Список | pgsql-hackers |
On Wed, 5 Jun 2024 at 19:53, Jeff Davis <pgsql@j-davis.com> wrote: > Is this orthogonal to relocatability? It's fairly orthogonal, but it has some impact on relocatability: You can only relocate to a schema name that does not exist yet (while currently you can only relocate to a schema that already exists). This is because, for owned_schema=true, relocation is not actually changing the schema of the extension objects, it only renames the existing schema to the new name. > When you say "an easy way to use a safe search_path": the CREATE > EXTENSION command already sets the search_path, so your patch just > ensures that it's empty (and therefore safe) first, right? Correct: **safe** is the key word in that sentence. Without owned_schema, you get an **unsafe** search_path by default unless you go out of your way to set "schema=pg_catalog" in the control file. > Should we go further and try to prevent creating objects in an > extension-owned schema with normal SQL? That would be nice for sure, but security wise it doesn't matter afaict. Only the creator of the extension would be able to add stuff in the extension-owned schema anyway, so there's no privilege escalation concern there. > Approximately how many extensions should be adjusted to use > owned_schema=true? Adjusting existing extensions would be hard at the moment, because the current patch does not introduce a migration path. But basically I think for most new extension installs (even of existing extensions) it would be fine if owned_schema=true would be the default. I didn't propose (yet) to make it the default though, to avoid discussing the tradeoff of security vs breaking installation for an unknown amount of existing extensions. I think having a generic migration path would be hard, due to the many ways in which extensions can now be installed. But I think we might be able to add one fairly easily for relocatable extensions: e.g. "ALTER EXTESION SET SCHEMA new_schema OWNED_SCHEMA", which would essentially do CREATE SCHEMA new_schema + move all objects from old_schema to new_schema. And even for non-relocatable one you could do something like: CREATE SCHEMA temp_schema_{random_id}; -- move all objects from ext_schema to temp_schema_{random_id}; DROP SCHEMA ext_schema; -- if this fails, ext_schema was not empty ALTER SCHEMA temp_schema_{random_id} RENAME TO ext_schema; > What are the reasons an extension would not want to > own the schema in which the objects are created? I assume some would > still create objects in pg_catalog, but ideally we'd come up with a > better solution to that as well. Some extensions depend on putting stuff into the public schema. But yeah it would be best if they didn't. > This protects the extension script, but I'm left wondering if we could > do something here to make it easier to protect extension functions > called from outside the extension script, also. It would be nice if we > could implicitly tack on a "SET search_path TO @extschema@, pg_catalog, > pg_temp" to each function in the extension. I'm not proposing that, but > perhaps a related idea might work. Probably outside the scope of your > proposal. Yeah, this proposal definitely doesn't solve all security problems with extensions. And indeed what you're proposing would solve another major issue, another option would be to default to the "safe" search_path that you proposed a while back. But yeah I agree that it's outside of the scope of this proposal. I feel like if we try to solve every security problem at once, probably nothing gets solved instead. That's why I tried to keep this proposal very targeted, i.e. have this be step 1 of an N step plan to make extensions more secure by default.
В списке pgsql-hackers по дате отправления: