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 по дате отправления: