Re: Possibility to disable `ALTER SYSTEM`
От | Robert Haas |
---|---|
Тема | Re: Possibility to disable `ALTER SYSTEM` |
Дата | |
Msg-id | CA+TgmoYVf6dgzmjdfSRLBbKYsTmY4G4+wG37QY7i+w4JnuF4pQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Possibility to disable `ALTER SYSTEM` (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Possibility to disable `ALTER SYSTEM`
|
Список | pgsql-hackers |
On Mon, Mar 25, 2024 at 1:47 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > FWIW, I never objected to the idea of being able to disable ALTER > SYSTEM. I felt that it ought to be part of a larger feature that > would provide a more bulletproof guarantee that a superuser can't > alter the system configuration; but I'm clearly in the minority > on that. I'm content with just having it disable ALTER SYSTEM > and no more, as long as the documentation is sufficiently clear > that an uncooperative superuser can easily bypass this if you don't > back it up with filesystem-level controls. OK, great. The latest patch doesn't specifically talk about backing it up with filesystem-level controls, but it does clearly say that this feature is not going to stop a determined superuser from bypassing the feature, which I think is the appropriate level of detail. We don't actually know whether a user has filesystem-level controls available on their system that are equal to the task; certainly chmod isn't good enough, unless you can prevent the superuser from just running chmod again, which you probably can't. An FS-level immutable flag or some other kind of OS-level wizardry might well get the job done, but I don't think our documentation needs to speculate about that. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: