|From:||Stephen Frost <sfrost(at)snowman(dot)net>|
|To:||Zhaomo Yang <zhy001(at)cs(dot)ucsd(dot)edu>|
|Cc:||pgsql-hackers(at)postgresql(dot)org, tgl(at)sss(dot)pgh(dot)pa(dot)us, Craig Ringer <craig(at)2ndquadrant(dot)com>, kaigai(at)ak(dot)jp(dot)nec(dot)com, Kirill Levchenko <klevchen(at)cs(dot)ucsd(dot)edu>|
|Subject:||Re: A mechanism securing web applications in DBMS|
|Views:||Raw Message | Whole Thread | Download mbox|
* Zhaomo Yang (zhy001(at)cs(dot)ucsd(dot)edu) wrote:
> You are right. Using unlogged table is a good idea. I'll try it out.
> Thanks for your advice!
Happy to help. Another option would be to have a custom GUC for this
information. The issue we have with that currently is that it can be
set by anyone.. Your extension could create one and register functions
which are called when it's set though, and only allow it to be set when
the auth/deauth functions are used. This would get rid of the need for
any kind of table.
> Currently auth functions are security definer functions. I'm gonna try
> to create a patch using unlogged table + RLS and put it online (e.g.
> this mail list) so that people can try it.
I'd strongly suggest that you look into creating PostgreSQL extensions
and using that mechanism as a way to distribute your security definer
functions and other components of this solution as a single, complete,
package which users can install with just "CREATE EXTENSION ...". That
might help with both getting others to test and play with your solution.
|Next Message||Andres Freund||2014-09-22 23:02:55||RLS feature has been committed|
|Previous Message||Andres Freund||2014-09-22 21:01:07||Re: better atomics - v0.6|