simply custom variables protection

"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. +