Re: function body actors (was: [PERFORM] viewing source code)
От | Tom Lane |
---|---|
Тема | Re: function body actors (was: [PERFORM] viewing source code) |
Дата | |
Msg-id | 5892.1198253938@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: function body actors (was: [PERFORM] viewing source code) ("Pavel Stehule" <pavel.stehule@gmail.com>) |
Список | pgsql-hackers |
"Pavel Stehule" <pavel.stehule@gmail.com> writes: > On 21/12/2007, Merlin Moncure <mmoncure@gmail.com> wrote: >> ... The real issue as I see it is where to >> keep the key. How did you handle that? > Simply. I use for password some random plpgsql message text and > compile it. I though about GUC, and about storing password in > postgresql.conf. It's equal to protection level. We cannot protect > code on 100%. If you have admin or superuser account and if you know > some internal, you can simply get code. Yeah. There is no defense against someone who is prepared to go in there with a debugger and pull the post-decryption code out of memory. So what we need to think about is what sorts of threats we *can* or should defend against. A couple of goals that seem like they might be reasonable are: * Even a superuser can't get the code at the SQL level, ie, it's secure if you rule out debugger-level attacks. (For example, this might prevent someone who had remotely breached the superuser account from getting the code.) * Code not available if you just look at what's on-disk, ie, you can't get it by stealing a backup tape. Any other threats we could consider defending against? BTW, this thread definitely doesn't belong on -performance anymore. regards, tom lane
В списке pgsql-hackers по дате отправления: