Jeff Davis <pg...@j-davis.com> writes: >> So maybe we should have “SECURITY DEFINER” and “SECURITY INVOKER” >> extension templates, the default being “SECURITY DEFINER”? > > That doesn't seem to answer Heikki's stated concern, because a malicious > non-superuser would just declare the trojan extension to be SECURITY > INVOKER.
It does answer if only superusers are allowed to install SECURITY INVOKER templates, which I forgot to add in the previous email. Or at least my understanding is that it could work that way. > As I see it, the problem is more about namespacing than anything else. > It's analogous to a shell which includes the current directory in the > $PATH -- a malicious user can just name an executable "ls" and trick > root into executing it. The solution for a shell has nothing to do with > setuid; so I'm reluctant to base our solution on SECURITY DEFINER. > > I prefer a solution that prevents the kind of name collisions that would > trick a privileged user. My strawman idea was to just say that an > extension template created by a non-superuser could only be instantiated > by that same user. Yes that's a simpler model. And simpler is better when talking security. The only drawback of that is to forbid the superuser from executing a command. That would be new in PostgreSQL I think. We can work around that with automating the SET ROLE to the template owner when a superuser is creating the extension. That's what led me to the SECURITY DEFINER proposition. Either of those solution are fine to me, with or without the automated SET ROLE when a superuser is installing an extension from a template owned by a non-superuser. Tell me your preference, I'll work on the code. >> Also consider multi-tenancy installations. Certainly, you don't want any >> database owner to be able to review PL code from any other database >> owner in the same cluster when each database owner is another customer. > > That could be solved by permissions, as well, right? I still think about extensions as being a per-database thing, and that the current security policy makes if a per-major-version thing when the extension contains a module (.so). Also, the dynamic_library_path already allows us to make binary extensions a per-database object again, baring incompatibilities that would manifest themselves as run-time errors… So I strongly vote against making the Extension Templates a set of shared catalogs. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers