RFC: Security and Impersonation - Initial Plan - Mailing list pgsql-hackers

From Philip Warner
Subject RFC: Security and Impersonation - Initial Plan
Date
Msg-id 3.0.5.32.19990726124356.009f4a90@mail.rhyme.com.au
Whole thread Raw
List pgsql-hackers
Having looked, albeit briefly, at what I think is the relevant code, I have
now come up with a plan.

1. Don't introduce modules. For the moment, just introduce features
consistent with handling modules later. The reasons for this are: (1) I
don't really like them yet and we don't need them, since I would not plan
to add other module features, (2) If they are the only way to define
functions, then it breaks a lot of people's databases, and (3) It's more
work than I want to do and would (probably) substantially affect all
external languages, and I'm sure I don't want to get into that yet.

2. Modify the CREATE FUNCTION definition as follows:

CREATE FUNCTION name ( [ ftype [, ...] ] )   RETURNS rtype   AS path   LANGUAGE 'langname'   [AUTHORIZATION 'authid']

where authid is any valid user/group. Defaults to none/NULL/empty. This
also means pg_dump would have to change - is that right? Or is it handles
automagically by the parser?

3. [Possibly] add a new statement: 'SET AUTHORIZATION ON FUNCTION name( [
ftype [, ...] ] ) TO authid'.

4. Modify the code that executes (or plans?) functions to push the relevant
auth-id onto a stack when the function is executed (if AUTH ID is not
specified in the function, use the prevailing auth-id). I guess it would be
better to modify the query planner, since we only want to retrieve security
information once. I'll need to be careful to 'catch' anything that rapidly
unwinds the stack of call frames (in the case of an error, for example).

5. Create a new function PgGetAuthID which returns the current active Auth
ID from the stack.

6. Modify any existing code that checks security by calling PgGetUserName
to now call 'PgGetAuthID'.

7. Do whatever the SQL3 standard says about CURRENT_USERNAME and add an
appropriate method of getting the real user as well as the current auth id.

Does this sound reasonable? Can somebody who knows a little more about the
internals, tell me if I am being ridiculously naieve?


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.C.N. 008 659 498)             |          /(@)   ______---_
Tel: +61-03-5367 7422            |                 _________  \
Fax: +61-03-5367 7430            |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


pgsql-hackers by date:

Previous
From: "D'Arcy" "J.M." Cain
Date:
Subject: Re: [HACKERS] Problem with dlopen and PostgreSQL - load of file failed
Next
From: "D'Arcy" "J.M." Cain
Date:
Subject: Re: [HACKERS] Problem with dlopen and PostgreSQL - load of file failed