On Mon, Jun 24, 2024 at 3:37 PM David E. Wheeler <david@justatheory.com> wrote:
> I guess the question then is what security controls are appropriate for this feature, which after all tells the
postmasterwhat directories to read files from. It feels a little outside the scope of a regular user to even be aware
ofthe file system undergirding the service. But perhaps there’s a non-superuser role for whom it is appropriate?
As long as the GUC is superuser-only, I'm not sure what else there is
to do here. The only question is whether there's some reason to
disallow this even from the superuser, but I'm not quite seeing such a
reason.
> > On the patch itself, I find the documentation for this to be fairly
> > hard to understand. I think it could benefit from an example. I'm
> > confused about whether this is intended to let me search for
> > extensions in /my/temp/root/usr/lib/postgresql/... by setting
> > extension_directory=/my/temp/dir, or whether it's intended me to
> > search both /usr/lib/postgresql as I normally would and also
> > /some/other/place.
>
> I sketched them quickly, so agree they can be better. Reading the code, I now see that it appears to be the former
case.I’d like to advocate for the latter.
Sounds good.
> > If the latter, I wonder why we don't handle shared
> > libraries by setting dynamic_library_path and then just have an
> > analogue of that for control files.
>
> The challenge is that it applies not just to shared object libraries and control files, but also extension SQL files
andany other SHAREDIR files an extension might include. But also, I think it should support all the pg_config
installationtargets that extensions might use, including:
>
> BINDIR
> DOCDIR
> HTMLDIR
> PKGINCLUDEDIR
> LOCALEDIR
> MANDIR
>
> I can imagine an extension wanting or needing to use any and all of these.
Are these really all relevant to backend code?
--
Robert Haas
EDB: http://www.enterprisedb.com
