RFC: Security and Impersonation - Initial Plan

Поиск
Список
Период
Сортировка
От Philip Warner
Тема RFC: Security and Impersonation - Initial Plan
Дата
Msg-id 3.0.5.32.19990726124356.009f4a90@mail.rhyme.com.au
обсуждение исходный текст
Список 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 по дате отправления:

Предыдущее
От: "D'Arcy" "J.M." Cain
Дата:
Сообщение: Re: [HACKERS] Problem with dlopen and PostgreSQL - load of file failed
Следующее
От: "D'Arcy" "J.M." Cain
Дата:
Сообщение: Re: [HACKERS] Problem with dlopen and PostgreSQL - load of file failed