On Tue, Jul 19, 2016 at 2:59 AM, Haribabu Kommi <kommi.harib...@gmail.com> wrote: > During the discussion of supporting multi tenancy with the help of > row level security, because of some problems of executing any > policy that was created by an unprivileged user . > > To avoid that problem, If we have some kind of new mechanism to > GRANT/REVOKE only CREATE POLICY from all the unprivileged > users by providing other CREATE access to them. > > I just want to know is there any other such requirements that if such > option is available, it would be good or not? I don't know whether > this option is possible or not? If any such requirements are present > other than POLICY, i would like to analyze and propose a patch for > the same.
Well, there are lots of things that users can do that might cause security exposures for other users. I think it's fair to say that PostgreSQL - like many other systems, really - is going to work best when either all of the users trust each other or when they are well-isolated from each other (i.e. in separate databases). If one user can get another to execute code, then that second user can usurp the privileges of the first user. CREATE POLICY provides one way of accomplishing that, but it's not necessarily qualitatively different from any other mechanisms that we've had for a long time: CREATE TRIGGER, CREATE FUNCTION, CREATE AGGREGATE, CREATE OPERATOR, and CREATE VIEW are all plausible ways of inducing another user to run your evil, malicious code. So I don't think that the right solution is to restrict CREATE POLICY in particular. It might be useful to have some kind of general system for limiting the ability of certain users to run certain commands, but I'm not sure how much demand there really is for such a thing. I think it's already possible using ProcessUtilityHook, if you're willing to write a small amount of C code. Do our users want more? Very possibly. Do I know exactly what they want? No, I don't. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers