Zhaomo,
* Zhaomo Yang (zhy...@cs.ucsd.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 any
Stephen,
> Yes- but that's pretty trivially done, given that you've stipulated that
> a single connection DB connection must be used from authentication until
> de-authentication. All that is needed is an additional column in the
> auth table which is populated with a pseudo-random value which is
Zhaomo,
* Zhaomo Yang (zhy...@cs.ucsd.edu) wrote:
> > Have you considered just using a regular, but unlogged, table? That
> > would also avoid any risk that the application manages to drop or shadow
> > the temp table somehow with a "fake" table that changes who is currently
> > authenticated, an
Stephen,
> As an FYI- we generally prefer inline responses rather than top-posting on
> the PostgreSQL mailing lists. Thanks.
Sorry for that.
> > - Try to make our mechanism as simple as possible.
> > Web application developers have all kinds of backgrounds. If the
> > security mechanism is to
* Zhaomo Yang (zhy...@cs.ucsd.edu) wrote:
> I am surprised to hear this too. :) We haven't talked to many web
> developers yet and this is one of the things we need to do in the
> future.
Certainly an excellent idea to talk to your target audience. :)
> The goal of this mechanism is to add anothe
Stephen,
There are several things I want to explain:
(1) Two philosophies important to our design
- Try to not force web application developers to make too many changes
to their apps if they wa.
- Try to make our mechanism as simple as possible.
Web application developers have all kinds of backgr
Zhaomo,
As an FYI- we generally prefer inline responses rather than
top-posting on the PostgreSQL mailing lists. Thanks.
* Zhaomo Yang (zhy...@cs.ucsd.edu) wrote:
> (1) Two philosophies important to our design
> - Try to not force web application developers to make too many changes
> to thei
On Fri, Sep 5, 2014 at 12:21 AM, Laurence Rowe wrote:
>
>
> Here my_auth_function would validate the ticket and would need to be able
> to do two things not currently possible with a SECURITY DEFINER function:
>
> 1. Call SET SESSION AUTHORIZATION / SET ROLE to become a user the
> connection user
> > 2.1 The authentication problem
> > We address the authentication problem by requiring developers to
> > define an authentication function in the DBMS. This function is
> > invoked whenever an application-level user logs in. An authentication
> > function contains the authentication logic in the
Zhaomo,
* Zhaomo Yang (zhy...@cs.ucsd.edu) wrote:
> I am a graduate student from UC San Diego. My adviser, Dr. Kirill
> Levchenko, and I have been working on a web/DB security project for
> the last few months. Since fine-grained access control in DBMS is part
> of our project and the PostgreSQL c
10 matches
Mail list logo
