Re: glob support in extension_control_path/dynamic_library_path?

On Jun 24, 2026, at 17:19, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:

> Security seems to be an interesting question for this.
>
> The current patch simply takes a wildcard, and evaluates it every time
> it is needed. Is that the correct approach? The advantage is that when
> a new directory matching the pattern appears, it is automatically
> detected... but that's also the disadvantage.

What’s the disadvantage, exactly? Sure, an attacker could stick a new directory in the wild-carded path and it will suddenly be available, but they can also just stick a dynamic library in any directory in a dynamic_library_path and it’ll be available. How is a wild carded directory worse than the current wildcarding, essentially, of DSOs and control files?

I suppose an attacker could add a directory that contains files with the same names as others, in the hopes they’d be found first in a search. We could potentially account for that by requiring that the directory have the same name as the control file being loaded, and for libraries perhaps allow “dir_name/filename” to ensure no other directory can replace it.

> Wouldn't it be better to freeze the current list of matching
> directories on configuration load, and require pg_reload_conf to add
> the newly matching patterns? With possibly additional helper functions
> that show what the patterns currently match compared to what's loaded
> by the active configuration? That's more complex, but could limit
> surprises.

I could see that. Limit it to the subdirectories found on startup or after the latest pg_reload_conf and report the delta (or just list what it found). Makes sense to me, assuming pg_reload_conf works as expected in environments like Postgres.app and CNPG (I don’t see why it wouldn’t).

> Should it require ownership/permission checks on the pattern parts
> somehow, or some other limitation?
>
> Also, while glob symbols are unlikely in filenames, they can be valid.
> Can backward compatibility be a possible concern, or accidental glob
> patterns from old configurations? For example a "/pg[18]/" directory
> would have a different meaning before/after.

Perhaps we could limit globbing to `*`?

> + glob_status = glob(mangled, GLOB_BRACE | GLOB_ERR, NULL, &globres
>
> I think GLOB_BRACE isn't POSIX? Based on a quick search it isn't
> available on Solaris, for example.

Best to use the standard, yeah.

Best,

David