Re: [PATCHES] simply custom variables protection
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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] 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
Re: [PATCHES] simply custom variables protection
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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] simply custom variables protection
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 [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] simply custom variables protection
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 [EMAIL PROTECTED] To: Pavel Stehule [EMAIL PROTECTED] CC: pgsql-patches@postgresql.org, [EMAIL PROTECTED], [EMAIL PROTECTED] 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] 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/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] simply custom variables protection
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 [EMAIL PROTECTED] To: Pavel Stehule [EMAIL PROTECTED] CC: pgsql-patches@postgresql.org, [EMAIL PROTECTED], [EMAIL PROTECTED] 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] simply custom variables protection
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] simply custom variables protection
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 [EMAIL PROTECTED] To: Pavel Stehule [EMAIL PROTECTED] CC: pgsql-patches@postgresql.org, [EMAIL PROTECTED], [EMAIL PROTECTED] 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] simply custom variables protection
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/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] simply custom variables protection
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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] simply custom variables protection
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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] simply custom variables protection
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] simply custom variables protection
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] simply custom variables protection
Pavel Stehule [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] simply custom variables protection
Pavel Stehule [EMAIL PROTECTED] 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
