On Jun 24, 2026, at 17:19, Zsolt Parragi <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP
