Thread: proposal: custom variables management
Hello This proposal is about access managenent to custom variables. Currently any user can modify it, and isn't way to protect value: Premises: * variables are controlled from modules * syntax of custom variables is without changes * all modules are safe Functions: * reset_custom_variable(cusvar); ... set default from postgresql.conf * revoke_custom_variable(READ|MODIFY, cusvar, roleid); * grant_custom_variable(READ|MODIFY, cusvar, roleid); Related discussion: http://archives.postgresql.org/pgsql-hackers/2007-03/msg00153.php Regards Pavel Stehule _________________________________________________________________ Play Flexicon: the crossword game that feeds your brain. PLAY now for FREE.� http://zone.msn.com/en/flexicon/default.htm?icid=flexicon_hmtagline
"Pavel Stehule" <pavel.stehule@hotmail.com> writes: > * reset_custom_variable(cusvar); ... set default from postgresql.conf > * revoke_custom_variable(READ|MODIFY, cusvar, roleid); > * grant_custom_variable(READ|MODIFY, cusvar, roleid); This seems pointlessly complex. An unprivileged user can only SET the value within his own session, and if there are any reasons he shouldn't be able to set it, the existing GUC protection categories seem sufficient. What's the use-case for all this new mechanism? > Related discussion: > http://archives.postgresql.org/pgsql-hackers/2007-03/msg00153.php Considering no one's bothered to implement that yet, I don't see that there's a groundswell of demand for something more complicated. regards, tom lane
>"Pavel Stehule" <pavel.stehule@hotmail.com> writes: > > * reset_custom_variable(cusvar); ... set default from postgresql.conf > > * revoke_custom_variable(READ|MODIFY, cusvar, roleid); > > * grant_custom_variable(READ|MODIFY, cusvar, roleid); > >This seems pointlessly complex. An unprivileged user can only SET the >value within his own session, and if there are any reasons he shouldn't >be able to set it, the existing GUC protection categories seem >sufficient. What's the use-case for all this new mechanism? > I would to use custom variables like session variables and I thing so can be usefull for security definer procedures. But I count with sharing current code. With described functions I don't need distribute superusers access. I am not sure, how much code I have to write. Maybe too much. Then I'll prefer minimalistic version later: reset_custom_variable(cusvar); armor custom_variable(cusvar); I would to test more general solution first > > Related discussion: > > http://archives.postgresql.org/pgsql-hackers/2007-03/msg00153.php > >Considering no one's bothered to implement that yet, I don't see that >there's a groundswell of demand for something more complicated. > > regards, tom lane _________________________________________________________________ Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. http://www.msn.cz/
Pavel Stehule wrote: > >> "Pavel Stehule" <pavel.stehule@hotmail.com> writes: >> > * reset_custom_variable(cusvar); ... set default from postgresql.conf >> > * revoke_custom_variable(READ|MODIFY, cusvar, roleid); >> > * grant_custom_variable(READ|MODIFY, cusvar, roleid); >> >> This seems pointlessly complex. An unprivileged user can only SET the >> value within his own session, and if there are any reasons he shouldn't >> be able to set it, the existing GUC protection categories seem >> sufficient. What's the use-case for all this new mechanism? >> > > I would to use custom variables like session variables and I thing so > can be usefull for security definer procedures. But I count with > sharing current code. With described functions I don't need distribute > superusers access. I am not sure, how much code I have to write. Maybe > too much. Then I'll prefer minimalistic version later: > > reset_custom_variable(cusvar); > armor custom_variable(cusvar); > > I would to test more general solution first > > >> > Related discussion: >> > http://archives.postgresql.org/pgsql-hackers/2007-03/msg00153.php >> >> Considering no one's bothered to implement that yet, I don't see that >> there's a groundswell of demand for something more complicated. >> >> Pavel, ISTM you are trying to do too much. We need to get the base functionality, as described by Tom in the thread I referred you to, working first. Extra stuff could be added later if necessary. cheers andrew
> >ISTM you are trying to do too much. We need to get the base functionality, >as described by Tom in the thread I referred you to, working first. Extra >stuff could be added later if necessary. > >cheers > I don't wont to build cathedral. Now is time for discussion, no? I am collect any arguments. With "enhanced" custom variables we can fill modules hole in plpgsql or any pl. With it security definer's procedures in any languages can safety share values. I worked on large wramework designed for plpgsql, and we had to store some temp values in temporary tables. Safe custom variables can be solution. It's only idea, nothing more. Regards Pavel Stehule _________________________________________________________________ Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/
Pavel Stehule wrote: >> >> ISTM you are trying to do too much. We need to get the base >> functionality, as described by Tom in the thread I referred you to, >> working first. Extra stuff could be added later if necessary. >> >> cheers >> > > I don't wont to build cathedral. Now is time for discussion, no? I am > collect any arguments. With "enhanced" custom variables we can fill > modules hole in plpgsql or any pl. With it security definer's > procedures in any languages can safety share values. I worked on large > wramework designed for plpgsql, and we had to store some temp values > in temporary tables. Safe custom variables can be solution. It's only > idea, nothing more. > Right now the main uses I have seen referred to only involve doing custom variables right, rather than exposing any extra API. For example, in plperl we might have a variable that contains a list of modules considered safe to load, and preload them. We would obviously want that to be PGC_SUSET, at least. But this only needs DefineCustomFooVariable() to work right. Nothing would need to be exposed to plperl itself, and no extra functionality is needed for at the C level. If you think there's a case for some extra functionality to be exposed, maybe you could provide some more examples / use cases. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> If you think there's a
> case for some extra functionality to be exposed, maybe you could provide
> some more examples / use cases.
I think what Pavel is on about is making use of not-known-to-C-code
custom variables as all-purpose intrasession storage. However, I doubt
that insufficient granularity of protection is the first problem
standing in the way of that --- the GUC mechanism was never designed to
scale up to huge numbers of variables, and will likely start to perform
poorly if anyone tries to make extensive use of such variables. But
perhaps more to the point, I'm unconvinced that we should encourage
what's basically an abuse of the GUC mechanism. It's a handy hack at
the moment, but what if we want to change GUC later in a way that
prevents being backward compatible with this behavior? It's not
impossible for example that we might want to load the defining module
immediately when someone tries to set a custom variable, rather than
letting the value skate by unchecked. Also, while GUC is underdesigned
for the purpose of intrasession storage in some ways, it is overdesigned
in others --- the whole postgresql.conf, SIGHUP, etc mechanism is
irrelevant. So it's really a pretty poor fit. If we want to support
general-purpose intrasession variables, I think something other than GUC
ought to be providing 'em. (And, of course, it seems likely that you
could provide such functionality with a few functions in
your-favorite-PL, without any core changes at all.)
regards, tom lane
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > >> If you think there's a >> case for some extra functionality to be exposed, maybe you could provide >> some more examples / use cases. >> > > I think what Pavel is on about is making use of not-known-to-C-code > custom variables as all-purpose intrasession storage. However, I doubt > that insufficient granularity of protection is the first problem > standing in the way of that --- the GUC mechanism was never designed to > scale up to huge numbers of variables, and will likely start to perform > poorly if anyone tries to make extensive use of such variables. But > perhaps more to the point, I'm unconvinced that we should encourage > what's basically an abuse of the GUC mechanism. It's a handy hack at > the moment, but what if we want to change GUC later in a way that > prevents being backward compatible with this behavior? It's not > impossible for example that we might want to load the defining module > immediately when someone tries to set a custom variable, rather than > letting the value skate by unchecked. Also, while GUC is underdesigned > for the purpose of intrasession storage in some ways, it is overdesigned > in others --- the whole postgresql.conf, SIGHUP, etc mechanism is > irrelevant. So it's really a pretty poor fit. If we want to support > general-purpose intrasession variables, I think something other than GUC > ought to be providing 'em. (And, of course, it seems likely that you > could provide such functionality with a few functions in > your-favorite-PL, without any core changes at all.) > > > I think I agree with you :-) But then every PL needs to invent it's own variable persistence - maybe we should look at providing a general PL-visible persistence mechanism which is distinct from GUC, so we don't have to keep reinventing the wheel (YAML anyone?). I think the use I had in mind for properly working custom variables fits more squarely with common GUC usage, though. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> ... So it's really a pretty poor fit. If we want to support
>> general-purpose intrasession variables, I think something other than GUC
>> ought to be providing 'em. (And, of course, it seems likely that you
>> could provide such functionality with a few functions in
>> your-favorite-PL, without any core changes at all.)
> I think I agree with you :-)
> But then every PL needs to invent it's own variable persistence
Why? You do it once, you can call it from SQL or any PL. Doing it in a
PL would constrain you to using a function-like syntax whereas a core
feature would have more flexibility of syntax, but I don't see that as a
big advantage --- looking at GUC's history, we've added function-style
APIs (current_setting() etc) when we already had specialized syntax.
regards, tom lane
>> > >I think I agree with you :-) > >But then every PL needs to invent it's own variable persistence - maybe we >should look at providing a general PL-visible persistence mechanism which >is distinct from GUC, so we don't have to keep reinventing the wheel (YAML >anyone?). > I know, so GUC aren't optimal for it. Any storage of Datum values can be better. I am thinking about using one row memory tables (similar ROW type from plpgsql). And access via clasic SQL statements. It's need only some game with executor and type cache. It can be cheaper than temporary tables with same functionality. Using: * trusted storage for debug info * trusted storage for state variables (vector) * trusted storage for expensive variables* trusted sharing values between PL >I think the use I had in mind for properly working custom variables fits >more squarely with common GUC usage, though. > I'll try implement my minimalistic version. Regards Pavel Stehule _________________________________________________________________ Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. http://www.msn.cz/
On Mon, Mar 05, 2007 at 06:54:36PM -0500, Andrew Dunstan wrote: > Tom Lane wrote: > >Andrew Dunstan <andrew@dunslane.net> writes: > > > >>If you think there's a case for some extra functionality to be > >>exposed, maybe you could provide some more examples / use cases. > > > >I think what Pavel is on about is making use of not-known-to-C-code > >custom variables as all-purpose intrasession storage. However, I > >doubt that insufficient granularity of protection is the first > >problem standing in the way of that --- the GUC mechanism was never > >designed to scale up to huge numbers of variables, and will likely > >start to perform poorly if anyone tries to make extensive use of > >such variables. But perhaps more to the point, I'm unconvinced > >that we should encourage what's basically an abuse of the GUC > >mechanism. It's a handy hack at the moment, but what if we want to > >change GUC later in a way that prevents being backward compatible > >with this behavior? It's not impossible for example that we might > >want to load the defining module immediately when someone tries to > >set a custom variable, rather than letting the value skate by > >unchecked. Also, while GUC is underdesigned for the purpose of > >intrasession storage in some ways, it is overdesigned in others --- > >the whole postgresql.conf, SIGHUP, etc mechanism is irrelevant. So > >it's really a pretty poor fit. If we want to support > >general-purpose intrasession variables, I think something other > >than GUC ought to be providing 'em. (And, of course, it seems > >likely that you could provide such functionality with a few > >functions in your-favorite-PL, without any core changes at all.) > > I think I agree with you :-) > > But then every PL needs to invent it's own variable persistence - > maybe we should look at providing a general PL-visible persistence > mechanism which is distinct from GUC, so we don't have to keep > reinventing the wheel (YAML anyone?). YAML could work, but JSON <http://www.json.org/> is a lot less sensitive to what should be trivial matters of whitespace. Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote! Consider donating to PostgreSQL: http://www.postgresql.org/about/donate