proposal: only superuser can change customized_options
Hello
I want to use custmized option for security configuration one contrib
library. Currently customized options are usable only for default
configuration, because everybody can change it. It is substitution of global
variables.
Decision if option is protected or not can be based on name of option. Like:
customized_option = (utl_file)
utl_file.protected.dir = '/aaa:/bbb' .. can be modified by superuser
utl_file.readonly.dir = '/aaa:/mm' .. nobody can modify it
Regards
Pavel Stehule
_________________________________________________________________
Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/
"Pavel Stehule" <pavel.stehule@hotmail.com> writes:
I want to use custmized option for security configuration one contrib
library. Currently customized options are usable only for default
configuration, because everybody can change it. It is substitution of global
variables.
Decision if option is protected or not can be based on name of option.
I dislike making it depend on spelling. There was discussion of this
problem before, and we had a much saner answer: when the module that
defines the variable gets loaded, discard any local setting if the
correct protection level of the variable is SUSET or higher. See the
archives.
regards, tom lane
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Pavel Stehule" <pavel.stehule@hotmail.com>
CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] proposal: only superuser can change
customized_options Date: Fri, 02 Feb 2007 11:40:10 -0500"Pavel Stehule" <pavel.stehule@hotmail.com> writes:
I want to use custmized option for security configuration one contrib
library. Currently customized options are usable only for default
configuration, because everybody can change it. It is substitution ofglobal
variables.
Decision if option is protected or not can be based on name of option.I dislike making it depend on spelling. There was discussion of this
problem before, and we had a much saner answer: when the module that
defines the variable gets loaded, discard any local setting if the
correct protection level of the variable is SUSET or higher. See the
archives.regards, tom lane
I am finding it.
Thank You
Pavel Stehule
_________________________________________________________________
Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com.
http://www.msn.cz/
Pavel Stehule wrote:
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Pavel Stehule" <pavel.stehule@hotmail.com>
CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] proposal: only superuser can change
customized_options Date: Fri, 02 Feb 2007 11:40:10 -0500"Pavel Stehule" <pavel.stehule@hotmail.com> writes:
I want to use custmized option for security configuration one contrib
library. Currently customized options are usable only for default
configuration, because everybody can change it. It is substitutionof global
variables.
Decision if option is protected or not can be based on name of option.I dislike making it depend on spelling. There was discussion of this
problem before, and we had a much saner answer: when the module that
defines the variable gets loaded, discard any local setting if the
correct protection level of the variable is SUSET or higher. See the
archives.regards, tom lane
I am finding it.
Pavel,
Is there any chance you can work on this? I suspect I won't have time.
You can see the original thread here:
cheers
andrew