Re: Security lessons from liblzma
От | David E. Wheeler |
---|---|
Тема | Re: Security lessons from liblzma |
Дата | |
Msg-id | 757E6934-1CE0-4C68-A843-CC5E83F623D3@justatheory.com обсуждение исходный текст |
Ответ на | Re: Security lessons from liblzma (walther@technowledgy.de) |
Список | pgsql-hackers |
On Apr 1, 2024, at 06:55, walther@technowledgy.de wrote: > Also a configurable directoy to look up extensions, possibly even to be changed at run-time like [2]. The patch says this: > >> This directory is prepended to paths when loading extensions (control and SQL files), and to the '$libdir' directive whenloading modules that back functions. The location is made configurable to allow build-time testing of extensions thatdo not have been installed to their proper location yet. > > This seems like a great thing to have. This might also be relevant in light of recent discussions in the ecosystem aroundextension management. > > All the path-related issues have in common, that while it's easy to move files around to their proper locations later,they all need to adjust pg_config's output. Funny timing, I was planning to resurrect this old patch[1] and propose that patch this week. One of motivators is the increasinguse of Docker images in Kubernetes to run Postgres, where there’s a desire to keep the core service and extensionsimmutable, and to have a second directory mounted to a persistent volume into which other extensions can be installedand preserved independently of the Docker image. The current approach involves symlinking shenanigans[2] that complicate things pretty substantially, making it more difficultto administer. A second directory fit for purpose would be far better. There are some other motivators, so I’ll do some additional diligence and start a separate thread (or reply to the original[3]). Best, David [1] https://commitfest.postgresql.org/5/170/ [2] https://speakerdeck.com/ongres/postgres-extensions-in-kubernetes?slide=14 [3] https://www.postgresql.org/message-id/flat/51AE0845.8010600%40ocharles.org.uk
В списке pgsql-hackers по дате отправления: