Re: A mechanism securing web applications in DBMS

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
Date: 2014-09-22 21:22:10
Message-ID: 20140922212209.GZ16422@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

Zhaomo,

* 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.

Thanks!

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
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