Re: [PATCH] Fix leaky VIEWs for RLS - Mailing list pgsql-hackers

From Greg Stark
Subject Re: [PATCH] Fix leaky VIEWs for RLS
Date
Msg-id AANLkTikgjzjhLcDp-m1GBGUId6y_46xfpbaJq0pfU0Nm@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Fix leaky VIEWs for RLS  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Jun 8, 2010 at 1:46 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> KaiGai Kohei <kaigai@ak.jp.nec.com> writes:
>> In this case, is it unnecessary to expose the given argument in
>> the error message (from security perspective), isn't it?
>
> Yes, if all you care about is security and not usability, that looks
> like a great solution.  We're *not* doing it.

It's possible to take a more nuanced angle on this approach. You could
imagine a flag indicating whether the call is within a SECURE VIEW
which if enabled caused error messages to elide data taken from
arguments. In order for this not to destroy the code legibility I
think you would need to design some new %-escapes for error messages
to indicate such arguments or some similar trick. You wouldn't want to
have to put extra conditionals everywhere. And I'm not sure where to
conveniently put such a flag so it would have the right semantics.

It would still be a lot of work and a big patch, but mostly mechanical
and it wouldn't impact usability for any case where it wasn't
necessary. It would still have the problem described earlier that we
would keep finding new omissions for years. I can't see us
implementing variable taint tracking in C to do it automatically
though. Perhaps we could get it from one of the static analysis tools.


--
greg


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: How to get permission to debug postgres?
Next
From: KaiGai Kohei
Date:
Subject: Re: [PATCH] Fix leaky VIEWs for RLS