Thread: simply custom variables protection
Hello this patch contains function ArmorCustomVariables. This function set flag armored on any custom variable. From this moment only superuser can change this variable. p.s. use it together with ResetPGVariable() Regards Pavel Stehule _________________________________________________________________ Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. http://www.msn.cz/
Attachment
"Pavel Stehule" <pavel.stehule@hotmail.com> writes:
> this patch contains function ArmorCustomVariables. This function set flag
> armored on any custom variable. From this moment only superuser can change
> this variable.
Why is this a good idea? Why don't you just fix the problem as
previously agreed, namely make the GUC context values work properly
for custom variables?
regards, tom lane
>"Pavel Stehule" <pavel.stehule@hotmail.com> writes: > > this patch contains function ArmorCustomVariables. This function set >flag > > armored on any custom variable. From this moment only superuser can >change > > this variable. > >Why is this a good idea? Why don't you just fix the problem as >previously agreed, namely make the GUC context values work properly >for custom variables? > I am sorry, I don't see it. In my solution module knows own variables and can chose what want to do with its. So if I like ro variables, then I add into module init calling ResetPgVariables() and ArmorCustomVariables(), and without anything the behave is same like current.What do you though. Regards Pavel Stehule _________________________________________________________________ Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---------------------------------------------------------------------------
Pavel Stehule wrote:
> Hello
>
> this patch contains function ArmorCustomVariables. This function set flag
> armored on any custom variable. From this moment only superuser can change
> this variable.
>
> p.s. use it together with ResetPGVariable()
>
> Regards
> Pavel Stehule
>
> _________________________________________________________________
> Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com.
> http://www.msn.cz/
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes: > Your patch has been added to the PostgreSQL unapplied patches list at: > http://momjian.postgresql.org/cgi-bin/pgpatches > It will be applied as soon as one of the PostgreSQL committers reviews > and approves it. This patch was already objected to, on the grounds that it does not meet the previously-agreed-to design for handling non-USERSET custom variables. regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Your patch has been added to the PostgreSQL unapplied patches list at: > > http://momjian.postgresql.org/cgi-bin/pgpatches > > It will be applied as soon as one of the PostgreSQL committers reviews > > and approves it. > > This patch was already objected to, on the grounds that it does not > meet the previously-agreed-to design for handling non-USERSET custom > variables. I did not see that. Removed. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Patch removed from patch queue. --------------------------------------------------------------------------- Pavel Stehule wrote: > > >"Pavel Stehule" <pavel.stehule@hotmail.com> writes: > > > this patch contains function ArmorCustomVariables. This function set > >flag > > > armored on any custom variable. From this moment only superuser can > >change > > > this variable. > > > >Why is this a good idea? Why don't you just fix the problem as > >previously agreed, namely make the GUC context values work properly > >for custom variables? > > > > I am sorry, I don't see it. In my solution module knows own variables and > can chose what want to do with its. So if I like ro variables, then I add > into module init calling ResetPgVariables() and ArmorCustomVariables(), and > without anything the behave is same like current.What do you though. > > Regards > Pavel Stehule > > _________________________________________________________________ > Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/ > > > ---------------------------(end of broadcast)--------------------------- > TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Pavel, would you remind me how this is useful? --------------------------------------------------------------------------- Pavel Stehule wrote: > Hello > > this patch contains function ArmorCustomVariables. This function set flag > armored on any custom variable. From this moment only superuser can change > this variable. > > p.s. use it together with ResetPGVariable() > > Regards > Pavel Stehule > > _________________________________________________________________ > Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. > http://www.msn.cz/ [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Pavel, would you remind me how this is useful? > > --------------------------------------------------------------------------- > > Pavel Stehule wrote: > >> Hello >> >> this patch contains function ArmorCustomVariables. This function set flag >> armored on any custom variable. From this moment only superuser can change >> this variable. >> >> p.s. use it together with ResetPGVariable() >> >> Hasn't Tom already objected to this patch? cheers andrew
Andrew Dunstan wrote: > Bruce Momjian wrote: > > Pavel, would you remind me how this is useful? > > > > --------------------------------------------------------------------------- > > > > Pavel Stehule wrote: > > > >> Hello > >> > >> this patch contains function ArmorCustomVariables. This function set flag > >> armored on any custom variable. From this moment only superuser can change > >> this variable. > >> > >> p.s. use it together with ResetPGVariable() > >> > >> > > Hasn't Tom already objected to this patch? Yes, but the author has not replied, so I am giving the author a chance to justify the patch. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Hello Bruce My patch allows to allert somebody so any custom variable is protected. I dont understand Tom's arguments. Probably this patch do more than is necessary. Really important for protection is only calling ResetPGVariable() function. My funcionality has only information value. Regards Pavel Stehule >From: Bruce Momjian <bruce@momjian.us> >To: Pavel Stehule <pavel.stehule@hotmail.com> >CC: pgsql-patches@postgresql.org, andrew@dunslane.net, tgl@sss.pgh.pa.us >Subject: Re: [PATCHES] simply custom variables protection >Date: Sat, 7 Apr 2007 11:54:13 -0400 (EDT) > > >Pavel, would you remind me how this is useful? > >--------------------------------------------------------------------------- > >Pavel Stehule wrote: > > Hello > > > > this patch contains function ArmorCustomVariables. This function set >flag > > armored on any custom variable. From this moment only superuser can >change > > this variable. > > > > p.s. use it together with ResetPGVariable() > > > > Regards > > Pavel Stehule > > > > _________________________________________________________________ > > Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. > > http://www.msn.cz/ > >[ Attachment, skipping... ] > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 1: if posting/reading through Usenet, please send an appropriate > > subscribe-nomail command to majordomo@postgresql.org so that your > > message can get through to the mailing list cleanly > >-- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > >---------------------------(end of broadcast)--------------------------- >TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate _________________________________________________________________ Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/
Pavel Stehule wrote: > Hello Bruce > > My patch allows to allert somebody so any custom variable is protected. I > dont understand Tom's arguments. Probably this patch do more than is > necessary. Really important for protection is only calling ResetPGVariable() > function. My funcionality has only information value. How does a user protect a custom variable using your code? I don't see any API that would allow that. --------------------------------------------------------------------------- > > Regards > Pavel Stehule > > > >From: Bruce Momjian <bruce@momjian.us> > >To: Pavel Stehule <pavel.stehule@hotmail.com> > >CC: pgsql-patches@postgresql.org, andrew@dunslane.net, tgl@sss.pgh.pa.us > >Subject: Re: [PATCHES] simply custom variables protection > >Date: Sat, 7 Apr 2007 11:54:13 -0400 (EDT) > > > > > >Pavel, would you remind me how this is useful? > > > >--------------------------------------------------------------------------- > > > >Pavel Stehule wrote: > > > Hello > > > > > > this patch contains function ArmorCustomVariables. This function set > >flag > > > armored on any custom variable. From this moment only superuser can > >change > > > this variable. > > > > > > p.s. use it together with ResetPGVariable() > > > > > > Regards > > > Pavel Stehule > > > > > > _________________________________________________________________ > > > Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. > > > http://www.msn.cz/ > > > >[ Attachment, skipping... ] > > > > > > > > ---------------------------(end of broadcast)--------------------------- > > > TIP 1: if posting/reading through Usenet, please send an appropriate > > > subscribe-nomail command to majordomo@postgresql.org so that your > > > message can get through to the mailing list cleanly > > > >-- > > Bruce Momjian <bruce@momjian.us> http://momjian.us > > EnterpriseDB http://www.enterprisedb.com > > > > + If your life is a hard drive, Christ can be your backup. + > > > >---------------------------(end of broadcast)--------------------------- > >TIP 7: You can help support the PostgreSQL project by donating at > > > > http://www.postgresql.org/about/donate > > _________________________________________________________________ > Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/ -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes: > Pavel Stehule wrote: >> My patch allows to allert somebody so any custom variable is protected. > How does a user protect a custom variable using your code? I don't see > any API that would allow that. The call would have to come from the loadable library that defines the custom variable. However, the complaint I had was that we already have an API that should be able to do this, namely setting a protection level higher than PGC_USERSET in the DefineCustomVariable call. That doesn't work today, but the right answer is to make it work, not invent more functions. This was agreed to be the right approach some time ago, see thread here: http://archives.postgresql.org/pgsql-hackers/2006-11/msg00911.php Pavel's proposed patch complicates the API and the code, and offers only part of the same functionality, ie, the equivalent of PGC_SUSET; but I think that for example PGC_SIGHUP is a perfectly reasonable setting to want to use with a custom variable. Furthermore I believe the patch is incomplete/wrong, because it adds only one check on the "armored" flag, whereas PGC_SUSET affects behavior in a number of places. I also notice that it will make setting of a an armored custom variable from postgresql.conf fail outright in non-superuser sessions, which is surely not desirable. In short: this isn't a feature, it's a wart. regards, tom lane
> >How does a user protect a custom variable using your code? I don't see >any API that would allow that. > Every module is responsibile for protectiong own custom variables. Only module knows if some variable needs protection. And after module inicialisation module can call ArmorCustomVariable function. From this moment only superuser can modify this custom variable. If it call ResetPGVariable() function before then default value is protected. It's question if test for superuser is necessery, I hope so it's usefull and I have posibility write security definer function where I can safely modify custom variables. >--------------------------------------------------------------------------- > > > > > Regards > > Pavel Stehule > > > > > > >From: Bruce Momjian <bruce@momjian.us> > > >To: Pavel Stehule <pavel.stehule@hotmail.com> > > >CC: pgsql-patches@postgresql.org, andrew@dunslane.net, >tgl@sss.pgh.pa.us > > >Subject: Re: [PATCHES] simply custom variables protection > > >Date: Sat, 7 Apr 2007 11:54:13 -0400 (EDT) > > > > > > > > >Pavel, would you remind me how this is useful? > > > > > > >--------------------------------------------------------------------------- > > > > > >Pavel Stehule wrote: > > > > Hello > > > > > > > > this patch contains function ArmorCustomVariables. This function set > > >flag > > > > armored on any custom variable. From this moment only superuser can > > >change > > > > this variable. > > > > > > > > p.s. use it together with ResetPGVariable() > > > > > > > > Regards > > > > Pavel Stehule > > > > > > > > _________________________________________________________________ > > > > Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. > > > > http://www.msn.cz/ > > > > > >[ Attachment, skipping... ] > > > > > > > > > > > ---------------------------(end of >broadcast)--------------------------- > > > > TIP 1: if posting/reading through Usenet, please send an appropriate > > > > subscribe-nomail command to majordomo@postgresql.org so that >your > > > > message can get through to the mailing list cleanly > > > > > >-- > > > Bruce Momjian <bruce@momjian.us> http://momjian.us > > > EnterpriseDB >http://www.enterprisedb.com > > > > > > + If your life is a hard drive, Christ can be your backup. + > > > > > >---------------------------(end of >broadcast)--------------------------- > > >TIP 7: You can help support the PostgreSQL project by donating at > > > > > > http://www.postgresql.org/about/donate > > > > _________________________________________________________________ > > Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/ > >-- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + _________________________________________________________________ Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/
> >Furthermore I believe the patch is incomplete/wrong, because it adds >only one check on the "armored" flag, whereas PGC_SUSET affects behavior >in a number of places. I also notice that it will make setting of a >an armored custom variable from postgresql.conf fail outright in >non-superuser sessions, which is surely not desirable. > I don't protect this patch. I didn't understand original proposal well. Tom, I don't understand your last notice. Can you explain it, please. Pavel Stehule _________________________________________________________________ Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. http://www.msn.cz/
"Pavel Stehule" <pavel.stehule@hotmail.com> writes:
>> How does a user protect a custom variable using your code? I don't see
>> any API that would allow that.
> Every module is responsibile for protectiong own custom variables. Only
> module knows if some variable needs protection. And after module
> inicialisation module can call ArmorCustomVariable function. From this
> moment only superuser can modify this custom variable. If it call
> ResetPGVariable() function before then default value is protected.
Well, that's the other problem with this approach: the variable is
protected only against changes occurring *after* ArmorCustomVariable
is called. Throwing away the existing value using ResetPGVariable is
surely undesirable if the existing value was in fact set by a superuser.
What's worse, I think it is a security hole, because ResetPGVariable's
effects can be rolled back by aborting the transaction in which the
module load occurs.
In any case we've now got a three-step rather than one-step method
for setting up a custom variable, with various interesting failure
modes if you do the steps in the wrong order. This is not a clean
solution.
regards, tom lane
Patch rejected; please continue discussion and resubmit. --------------------------------------------------------------------------- Pavel Stehule wrote: > Hello > > this patch contains function ArmorCustomVariables. This function set flag > armored on any custom variable. From this moment only superuser can change > this variable. > > p.s. use it together with ResetPGVariable() > > Regards > Pavel Stehule > > _________________________________________________________________ > Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. > http://www.msn.cz/ [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +