Re: [0/4] Proposal of SE-PostgreSQL patches

"Greg Smith" <gsmith(at)gregsmith(dot)com> writes:

> The approach taken here is to put all the "#ifdef" logic into the underlying
> ACE interface (see patch [2/4]), so that the caller doesn't have to care. If
> SELinux support is off then the calls turns into
>
> void x(y) {} or
> bool a(b) { return true; }
>
> This is a very clean design, but it's putting extra (possibly optimized away)
> calls into a lot of places. While it would be uglier, it might make sense to
> put that on/off logic in all the places where the calls are made, so that when
> you turn SELinux support off most of the code really does go completely away
> rather than just turning into stubs.

It's nicer to do it the way they have but we don't generally trust compilers
to inline functions. Is it hard to make those functions into macros?

> -The only error reporting and handling method used is "elog(ERROR,...". That
> seems a bit heavy handed for something that can be expected to happen all the
> time.
>
> If I understand this correctly, when you're scanning a table with 1000 rows
> where you're only allowed to see 50% of them, that's going to be 500 call to
> elog(), one for each tuple you can't see. Having a tuple get screened out
> isn't really an error per se, and while I can see how sensitive installs would
> want those all reported there are others where this volume of log activity
> would be too much. Just because someone with classified clearance is looking
> at a big table that also has a lot of secret info in it, not all installs will
> want a million errors reported just because there's data that person can't see
> available.

I don't understand, if it's ERROR it would throw an error and stop the current
query. Or is this all within a PG_TRY() ?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!