Обсуждение: BUG #9136: pg_is_xlog_replay_paused() should not need Superuser
The following bug has been logged on the website: Bug reference: 9136 Logged by: Renato Ramonda Email address: sys-milan@statpro.com PostgreSQL version: 9.2.6 Operating system: Ubuntu 12.04 Description: The admin function pg_is_xlog_replay_paused() is read only and can be useful for monitoring, as such it should NOT require superuser privileges (as it does now). For reference, the read-only functions for monitoring the replication delay such as pg_current_xlog_location can be executed without superuser privileges (as remarked by the official documentation here http://www.postgresql.org/docs/9.1/static/functions-admin.html )
On Fri, Feb 7, 2014 at 10:16:36AM +0000, sys-milan@statpro.com wrote: > The following bug has been logged on the website: > > Bug reference: 9136 > Logged by: Renato Ramonda > Email address: sys-milan@statpro.com > PostgreSQL version: 9.2.6 > Operating system: Ubuntu 12.04 > Description: > > The admin function pg_is_xlog_replay_paused() is read only and can be useful > for monitoring, as such it should NOT require superuser privileges (as it > does now). > > For reference, the read-only functions for monitoring the replication delay > such as pg_current_xlog_location can be executed without superuser > privileges (as remarked by the official documentation here > http://www.postgresql.org/docs/9.1/static/functions-admin.html ) Is this correct? Do we have proper super-user restrictions on all the right fields now? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
On Thu, Apr 17, 2014 at 2:02 AM, Bruce Momjian <bruce@momjian.us> wrote: > On Fri, Feb 7, 2014 at 10:16:36AM +0000, sys-milan@statpro.com wrote: > > The following bug has been logged on the website: > > > > Bug reference: 9136 > > Logged by: Renato Ramonda > > Email address: sys-milan@statpro.com > > PostgreSQL version: 9.2.6 > > Operating system: Ubuntu 12.04 > > Description: > > > > The admin function pg_is_xlog_replay_paused() is read only and can be > useful > > for monitoring, as such it should NOT require superuser privileges (as it > > does now). > > > > For reference, the read-only functions for monitoring the replication > delay > > such as pg_current_xlog_location can be executed without superuser > > privileges (as remarked by the official documentation here > > http://www.postgresql.org/docs/9.1/static/functions-admin.html ) > > Is this correct? Do we have proper super-user restrictions on all the > right fields now? > I'm not sure what the security problem would be for allowing non-superusers to run pg_is_xlog_replay_paused(). And if there are none, there is no reason why the function should be restricted like that. Also, looking at that specific documentation page, ISTM it needs a better way to show which functions actually *do* require superuser privileges. In some groups it states which do require it, and in some where it doesn't. Perhaps we should add a column to each of the tables with a yes/no value indicating if superuser is required for that specific function? Or at least have every table be prefixed by a statement saying which require superuser. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Fri, Apr 18, 2014 at 03:11:44PM +0200, Magnus Hagander wrote: > Is this correct? Do we have proper super-user restrictions on all the > right fields now? > > > I'm not sure what the security problem would be for allowing non-superusers to > run pg_is_xlog_replay_paused(). And if there are none, there is no reason why > the function should be restricted like that. > > Also, looking at that specific documentation page, ISTM it needs a better way > to show which functions actually *do* require superuser privileges. In some > groups it states which do require it, and in some where it doesn't. Perhaps we > should add a column to each of the tables with a yes/no value indicating if > superuser is required for that specific function? Or at least have every table > be prefixed by a statement saying which require superuser. Well, right now we seem to have an inconsistent setup that is being complained about regularly. Who can review it all and make a recommendation? Should we just hold all this for 9.5? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
On Fri, Feb 7, 2014 at 8:16 AM, <sys-milan@statpro.com> wrote: > The admin function pg_is_xlog_replay_paused() is read only and can be > useful > for monitoring, as such it should NOT require superuser privileges (as it > does now). > Just as an workaround for this situation, you can create a function with SECURITY DEFINER that wraps the call of pg_is_xlog_replay_paused. Best regards, --=20 Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br n=C3=ADvel F! www.dextra.com.br/postgres
On Fri, Apr 18, 2014 at 10:53:23AM -0400, Bruce Momjian wrote: > On Fri, Apr 18, 2014 at 03:11:44PM +0200, Magnus Hagander wrote: > > Is this correct? Do we have proper super-user restrictions on all the > > right fields now? > > > > > > I'm not sure what the security problem would be for allowing non-superusers to > > run pg_is_xlog_replay_paused(). And if there are none, there is no reason why > > the function should be restricted like that. > > > > Also, looking at that specific documentation page, ISTM it needs a better way > > to show which functions actually *do* require superuser privileges. In some > > groups it states which do require it, and in some where it doesn't. Perhaps we > > should add a column to each of the tables with a yes/no value indicating if > > superuser is required for that specific function? Or at least have every table > > be prefixed by a statement saying which require superuser. > > Well, right now we seem to have an inconsistent setup that is being > complained about regularly. Who can review it all and make a > recommendation? Should we just hold all this for 9.5? I have developed the attached patch. I marked the xlog replay pause/resume functions as super-user, and marked the replication slots as super-user. I don't see any other place that is missing or needs a section heading. I don't think we need a new column as most functions in a section are either super-user only or not. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Вложения
On Tue, Aug 26, 2014 at 06:52:16PM -0400, Bruce Momjian wrote: > On Fri, Apr 18, 2014 at 10:53:23AM -0400, Bruce Momjian wrote: > > On Fri, Apr 18, 2014 at 03:11:44PM +0200, Magnus Hagander wrote: > > > Is this correct? Do we have proper super-user restrictions on all the > > > right fields now? > > > > > > > > > I'm not sure what the security problem would be for allowing non-superusers to > > > run pg_is_xlog_replay_paused(). And if there are none, there is no reason why > > > the function should be restricted like that. > > > > > > Also, looking at that specific documentation page, ISTM it needs a better way > > > to show which functions actually *do* require superuser privileges. In some > > > groups it states which do require it, and in some where it doesn't. Perhaps we > > > should add a column to each of the tables with a yes/no value indicating if > > > superuser is required for that specific function? Or at least have every table > > > be prefixed by a statement saying which require superuser. > > > > Well, right now we seem to have an inconsistent setup that is being > > complained about regularly. Who can review it all and make a > > recommendation? Should we just hold all this for 9.5? > > I have developed the attached patch. I marked the xlog replay > pause/resume functions as super-user, and marked the replication slots > as super-user. I don't see any other place that is missing or needs a > section heading. I don't think we need a new column as most functions in > a section are either super-user only or not. Patch applied, backpatch to 9.4. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +