On Mon, Feb 16, 2009 at 12:08 PM, KaiGai Kohei <kai...@kaigai.gr.jp> wrote: >>>> This is the same "covert channel", so why is it a problem for >>>> SE-Postgres and not for normal Postgres? >>> >>> Please note that I don't consider it is a problem, even if SE-PostgreSQL. >>> >>> Both of SE-PostgreSQL and vanilla PostgreSQL don't give an assurance to >>> eliminate information leaks via such kind of covert channels, so they >>> don't violate any specifications of them. Thus, it is not a problem. >> >> If that's true then I don't see why we would try to automatically hide >> records >> you don't have access to. The only reason to do so is to try to close >> these >> covert channels and if we can't do that then I don't see any benefit to >> doing >> so. > > It is incorrect. > It seems to me you confound a covert channel and granularity in access > controls. The purpose of row-level security is to provide users more > flexibility in access controls, not related to covert channels.
No, I claim it's you that's confounding the data hiding scheme with row-level granular access controls. If a user types "SELECT count(*) from table" they should either get the correct count of records from that table or get a permission failure. If they want to get the count of records for which they have read access they should have to write "SELECT count(*) from table where access_check(security_label, current_user())" or something like that. The only reason to make the above automatic is to hide from the user the fact that there are records they're not seeing. Since we can't do that effectively there's no point in having it at all, especially since it breaks the interpretation of the query in ways that interfere with other functionality. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers