2010/9/29 KaiGai Kohei <kai...@ak.jp.nec.com>: >> But with that exception, >> they seemed to think that coarse-grained permissions would be fine for >> a basic implementation: perhaps even just install something in >> ProcessUtility_hook and bounce DDL across the board, so long as it's >> controlled by reference to the security policy rather than by DAC. I >> think we can do better than that in a pretty short period of time if >> we avoid getting side-tracked, but the key is that we have to avoid >> getting side-tracked. >> > In this approach, we eventually need to deploy the hooks on object creation > as we are currently working on. So, I don't think using ProcessUtility_hook > for coarse-grained permissions is a right direction.
Well, it may be the easiest way to do certain things. For example, if you wanted to control access to a command such as LOAD (which presumably you do since otherwise a loadable module could trivially subvert the security policy), it's unclear to me that there's any need for a new hook; ProcessUtility_hook might very well be the best way to tackle that. We need to consider the best way to handle each case. In some cases, all of the necessary information may not be available when ProcessUtility_hook is called, but where it is, we shouldn't reinvent the wheel. With respect to this patch, I think we are on the same page now, with possibly some disagreement about how far it makes sense to go with this that needn't concern us for the present. I'm going to mark this patch Returned with Feedback, because we need to move on to other patches that are closer to being committable. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
