Hello list, I am posting here since Craig Ringer suggested user feedback on this feature at this time may make a difference for 9.4 inclusion. I apologize if I am in the wrong place.
Row-level security is probably THE major element the FOSS databases are behind compared to proprietary databases like Oracle or DB2. I understand that RLS was originally targeted for 9.3, slipped, was retargeted for 9.4, and will slip again. This is unfortunate, but I realize it’s a hard problem. It is possible for me to get about 90% of the way there by clever use of views. However views are not intrinsically secure, and well-crafted queries can leak the underlying table information. It is not immediately clear to me, as a user, if there is a way to lock down the user account hard enough to prevent this, but I suspect the answer is no. In theory security-barrier views solve this problem, but since you cannot INSERT or UPDATE a security-barrier view this only works for read-only applications. For read-write scenarios, some other solution must be taken for the write path. If UPDATE/INSERT on security-barrier views slips to 9.5, the impact to me personally is that I will have to create some kind of MITM proxy or write some kind of privilege-elevated process to handle the write path. I am willing to take on some tasks in support of solving this problem in 9.4, but my unfamiliarity with the codebase means that realistically I’m not of much help. Certainly, if there is something I could be doing, please let me know. Drew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
