From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> |
Cc: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Simon Riggs <simon(at)2ndQuadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Updates of SE-PostgreSQL 8.4devel patches (r1197) |
Date: | 2008-11-29 15:42:05 |
Message-ID: | 200811291542.mATFg5b11598@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
KaiGai Kohei wrote:
> Bruce Momjian wrote:
> > KaiGai Kohei wrote:
> >>> What I am saying is for the default compile, SQL-level ACLs should be
> >>> possible because, since the ACL field has optional storage, there is no
> >>> downside to have it be available by default.
> >> I think it is a possible and desirable desicion from the viewpoint of
> >> security folks.
> >>
> >> However, I think we have a few issues, and it makes unclear whether
> >> we can make an agreement in the community.
> >> The one is a cost of security hooks. They consume a bit more CPU steps
> >> when a security mechanism is enabled. The other is prevention to override
> >> a few hooks (ExecutorRun_hook and planner_hook), because they assume
> >> standard implementations to be executed.
> >>
> >> Which is more desirable option in the default?
> >
> > Well, my assumption is that if a table doesn't have SQL-level row
> > permissions then there is no overhead becaues there are no permissions
> > to check.
>
> When the binary is built with the SQL-level row permissions and scanned
> table does not activated it, all it does is checking a flag variable
> at Relation->rd_options. I guess it will be acceptable cost.
>
> In this case, DBA disables row-level permission on the table, so
> no additional security field is required.
>
> > For example, I might want to put SQL-level row permissions on an audit
> > table, but none of my other tables, and in that case I assume there is
> > only a performance impact on queries that use the audit table.
>
> It is not a zero, but tiny as far as we can ignore it in my opinion.
Yes. It is good to have SQL-level row security available by default in
every binary, even if it requires a few checks in C.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2008-11-29 15:56:42 | Re: Re: [COMMITTERS] pgsql: Add support for matching wildcard server certificates to the new |
Previous Message | Magnus Hagander | 2008-11-29 13:49:35 | Re: Re: [COMMITTERS] pgsql: Add support for matching wildcard server certificates to the new |