7 ms·

This should have always been the default behavior. Is it the default now? Shocked it never was since it is a major source of data leaks (which completely defea

• deleted 4y ago
  [deleted]
• tremon 4y ago
  You're mixing up two orthogonal concepts. In the absence of row-level security, allowing a user read access to a view only (which may only have a filtered or condensed view of the underlying tables) is the more secure solution. If such a view would only work if the user also had access to the raw underlying tables, that would be a major source of data leaks. In the presence of row-level security, the same concept allows you to create a system where (for example) the user can still access aggregate data for parts of the table where the individual rows are hidden to them. A simple example: a manager has full access to the salary records of his direct reports, but there's also a view that shows the wage balance per-team. If that view were to have invoke-as-user permissions, the manager would still only be able to view his own teams' wage balance. By making that view execute as security_definer instead, the admin can once again exercise full control over who gets access to which data. So no, I don't think it should not be the default behaviour, and no, it does not completely defeat the purpose of row-level security.