Re: securing pg_proc
От | Merlin Moncure |
---|---|
Тема | Re: securing pg_proc |
Дата | |
Msg-id | 6EE64EF3AB31D5448D0007DD34EEB3412A7657@Herge.rcsinc.local обсуждение исходный текст |
Ответ на | securing pg_proc ("Merlin Moncure" <merlin.moncure@rcsonline.com>) |
Ответы |
Re: securing pg_proc
|
Список | pgsql-hackers |
> "Merlin Moncure" <merlin.moncure@rcsonline.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
В списке pgsql-hackers по дате отправления: