Thread: AW: AW: "setuid" functions, a solution to the RI privil ege problem

> But the pg_shadow authentication is based on credentials 
> provided by the
> client whereas what you propose here would run on the server, so this
> doesn't make sense. 

Since you can write extensions to PostgreSQL that reach far into the OS,
it does make sense to execute those extensions under a "non priviledged"
user, and not postgres. This OS user would somehow be tied to the username
that the client passes as his credentials (and that we trust to be
authenticated).

This is actually not my idea, it is implemented in Informix, DB2 and I think
Oracle.

Andreas

Zeugswetter Andreas SB writes:

> Since you can write extensions to PostgreSQL that reach far into the OS,
> it does make sense to execute those extensions under a "non priviledged"
> user, and not postgres.

Agreed.

> This OS user would somehow be tied to the username that the client
> passes as his credentials (and that we trust to be authenticated).

Not agreed. It's a feature, not an accident, that client user names,
server OS user names, and database user names are independent. The mapping
of database user names to server OS user names needs to have a separate
mapping and authentication system, which could probably be similar to the
existing client authentication, but still separate.


-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/