Re: Hiding a GUC from SQL

Поиск
Список
Период
Сортировка
От Laurenz Albe
Тема Re: Hiding a GUC from SQL
Дата
Msg-id 10928ddb7c4d0727b0ee7f3c53a43a514061a2a7.camel@cybertec.at
обсуждение исходный текст
Ответ на Re: Hiding a GUC from SQL  (raf <raf@raf.org>)
Ответы Re: Hiding a GUC from SQL  (raf <raf@raf.org>)
Список pgsql-general
On Mon, 2020-06-22 at 09:44 +1000, raf wrote:
> A superuser can access files and start programs on the server machine.
> > A dedicated superuser may for example attach to PostgreSQL with a debugger
> > and read the value of the variable.
> > 
> > And if that doesn't work, there may be other things to try.
> > 
> > It is mostly useless to try to keep a superuser from doing anything that
> > the "postgres" operating system user can do.
> 
> But only mostly useless. :-) There are ways to limit the power of the
> superuser. On Linux, for instance, "sysctl kernel.yama.ptrace_scope=3"
> prevents tracing, debugging, and reading another process's memory, even
> by the superuser, and the only way to turn it off is via a (hopefully
> noticeable) reboot.

Interesting.  Will this block a user from debugging his own processes?
Perhaps you can plug that hole that way, but that was just the first thing
that popped in my head.  Don't underestimate the creativity of attackers.
I for one would not trust my ability to anticipate all possible attacks,
and I think that would be a bad security practice.

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com




В списке pgsql-general по дате отправления:

Предыдущее
От: Laurenz Albe
Дата:
Сообщение: Re: Feature suggestion: auto-prefixing SELECT query column nameswith table/alias names
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Definition of REPEATABLE READ