2012/3/12 Robert Haas <robertmh...@gmail.com>: > On Mon, Mar 12, 2012 at 12:30 PM, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: >>> Suppose that the connection starts out in context connection_pooler_t. >>> Based on the identity of the user, we transition to foo_t, bar_t, or >>> baz_t. If it's possible, by any method, for one of those contexts to >>> get back to connection_pooler_t, then we've got a problem. We give a >>> connection to user foo which is in foo_t; he transitions it back to >>> connection_pooler_t, then to bar_t, and usurps user bar's privileges. >>> Unless there's some way to prevent that, the only way to make this >>> secure is to make the transition to foo_t irreversible. >>> >> It is the reason why I advocate the idea to allow sepgsql_setcon() >> inside of trusted-procedures. >> >> The original use-case of Joshua does not allow connection_pooler_t >> to execute any SQL commands except for invocation of a particular >> trusted-procedures; that takes a secret credential as an argument, >> then it switches the client label to foo_t, bar_t or baz_t according to >> the supplied credential. >> These labels are allowed to switch back to the original >> connection_pooler_t, but it is unavailable to switch arbitrary label >> without suitable credential. > > Oh, I get it. > > Given that that's the intended use case, the current design does make > sense, but it seems awfully special-purpose. Not knowing that this is > what you had in mind, I never would have guessed the reason for all > this complexity. I worry that this is too much of a purpose-built > mechanism, and that nobody will ever be able to use it for much of > anything beyond the extremely specific use case that you've laid out > here. I think that, at the very least, the comments and documentation > need to make it clear that this is very deliberately intended to > modify only the toplevel security context of the session, which may be > different from the currently active context if a TP is in use; and > also that the change will apply to future transactions only if the > current transaction commits. > OK, I try to update the documentation and test cases with related security policy, rather than the code base itself.
Please wait for a few days to update them. -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
