AW: AW: AW: "setuid" functions, a solution to the RI pr ivil ege problem - Mailing list pgsql-hackers

From Zeugswetter Andreas SB
Subject AW: AW: AW: "setuid" functions, a solution to the RI pr ivil ege problem
Date
Msg-id 11C1E6749A55D411A9670001FA687963368084@sdexcsrv1.f000.d0188.sd.spardat.at
Whole thread Raw
List pgsql-hackers
> > 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


pgsql-hackers by date:

Previous
From: Karel Zak
Date:
Subject: odbc (was: Re: ascii to character conversion in postgres)
Next
From: Karel Zak
Date:
Subject: Re: char* to Datum conversion