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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
