> My concern is that superuser is allowed to modify system catalog > by hand, like: > > UPDATE pg_proc SET probin = '/tmp/malicious_library.so' > WHERE oid = ...; > > It is logically same as ALTER FUNCTION. > > Even if I remove a hook from simple_heap_xxxx(), it is necessary > to check queries from clients.
That's a valid concern, I think all we're saying here is that you need to find a better place to block that, maybe by assigning pg_proc an security label that prevents modification by the superuser. > IIRC, 0racle or M$ has a patent to rewrite WHERE clause for security > purpose, so Tom suggested it should be implemented using a hook > deployed within executor. > At least, it also enables code more simple. Patents suck. I guess we need to understand this issue better before we can make any decisions. > A wall between the data and _backend C code_ is not my intention. > > Its purpose is a wall between the data and clients including superuser > via SQL queries. It is a basic assumption we cannot acquire any accesses > from system internal entities, as SELinux do nothing for kernel loadable > modules. > > However, please note that making a decision at more hot point is more > good design, because it enables to reduce potential bypasses. > At the begining, I choosed simple_heap_xxxx() as a most hot point. > However, it can be replacable, if we can find any other place without > omission and consistent. That's why I was thinking about the planner... ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
