Simon Riggs wrote: > Also, we should presume that any function created with SECURITY DEFINER > and created by a superuser would have plan security, so we don't need to > annotate lots of old code to work securely. Annotating the built-in > functions is a lot easier.
SECURITY DEFINER is an orthogonal aspect. Consider something as innocent-looking as this: CREATE FUNCTION secdeffunc(text) RETURNS boolean AS $$ SELECT $1::integer < 10; $$ LANGUAGE SQL SECURITY DEFINER; The text-to-integer cast throws an error and reveals the argument as someone pointed out earlier in this thread. Creating such a function shouldn't open the door to information leaks in views elsewhere. The most useful "automatic" annotation I can see is to treat functions implementing B-tree operators as safe. I *think* that's safe, anyway. >> 2. If the view refers only one table (as a typical Veil view does), plan >> it like we do today but enforce that view conditions are evaluated first >> in the Filter. Notably, allow using any user-supplied conditions as >> index quals if there's a matching index. >> >> 3. Otherwise fully materialize the view. > > So if we join a normal table or a view to a secure view then only the > secure view part would be materialized? Or do you mean the whole query > would be materialized? Just the secure view. Materializing the result of the overall query wouldn't help. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
