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
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, and avoids
* 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 another
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 too alien
On Fri, Sep 5, 2014 at 12:21 AM, Laurence Rowe l...@lrowe.co.uk 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
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 their
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
Hi all,
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 community is also working on it now,
we would like
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
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
11 matches
Mail list logo
