Re: securing pg_proc

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "List pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: securing pg_proc
Date: 2005-03-17 16:50:21
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB3412A7657@Herge.rcsinc.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> writes:
> > 1. Am I totally off my rocker for suggesting users without 'execute'
> > priv. should not be able to view procedure source.
>
> 1. I don't particularly buy that, no. Why draw the line at seeing
> source code? The mere name and argument list might be considered
> 'sensitive' information.

Not a big deal considering where the line gets drawn, but this is moot
considering your next point. However, I'm a little unclear about where
you stand on the relative merit (whatever the implementation) of hiding
at the very least prosrc from non-priv users.

> 2. We haven't had a policy of hiding schema information in the past,
and
> I don't think it's the sort of thing that can usefully be bolted on
> piecemeal.

Well, at least one system catalog is a view + function (pg_locks),
albeit for completely different reasons.

> 3. The people who ask for this sort of thing frequently don't want
those
> with execute permission to look at the source, either, so your
proposed
> solution really isn't going to satisfy anybody.

It wouldn't? Your points #1 and #3 could be addressed by configuring
the view one way or another...so ISTM you are arguing for the
flexibility of a view, not against...

If the view approach is out, are there any other alternatives to
consider? Adding a new priv. for functions to GRANT seems to also pull
pg_proc towards a view.

Merlin

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-03-17 17:23:32 Re: securing pg_proc
Previous Message Tom Lane 2005-03-17 16:07:08 Re: securing pg_proc