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

Tue, 19 Sep 2000 09:50:55 +0200
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: AW: AW: "setuid" functions, a solution to the RI pr
	ivil  ege problem