AW: AW: AW: "setuid" functions, a solution to the RI pr ivil ege problem

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

Yes, a mapping is useful (as I said).

> and authentication system, which could probably be similar to the
> existing client authentication, but still separate.

I do not think that a separate authentication is necessary, it might be a
feature,
but imho the standard would be a trusted mapping from db to OS user.
Remember that execution rights are granted to db users for functions.
If a user does not have a desirable mapping you don't grant him any rights.

A special flag "suid" for functions would imply that the function always
runs under
the same OS user of the function owner, regardless of client credentials.

Andreas