Re: ALTER USER SET log_* not allowed...

Sean Chittenden <sean(at)chittenden(dot)org> writes:
>> It strikes me that a more useful definition would be to say that you
>> must be superuser, period, to install an ALTER USER/DATABASE value for
>> any USERLIMIT variable; and then we could treat these values as
>> privileged for USERLIMIT purposes. This would lose the ability for
>> non-superusers to set allowable values for themselves this way, but
>> I think the case we'd gain is more useful.

> Oh! Please! I thought about suggesting that but didn't think it'd
> pass your litmus test and figured a pg_shadow.useconfig and an
> pg_shadow.admconfig would be received better, but, absolutely! The
> reason I hesitated to suggest such a change was SET search_path = foo;,
> which a user should be able to set on their own.

But search_path is not USERLIMIT. The only variables that are in that
category are the ones that control logging.

Bruce and I were chatting about this on the phone today, and we were
seriously considering a more radical proposal: get rid of the whole
concept of USERLIMIT variables, and make the logging variables be plain
SUSET (ie, only superusers can change 'em). This would eliminate the
current ability of a non-superuser to increase the logging verbosity
of his session, but it's not real clear that that's such a good idea
anyway. (Cranking the log verbosity up far past what the DBA wants
could be seen as a primitive form of DOS attack; and anyway, if you are
not a superuser then you can't see what's in the log, so why should
you care what the verbosity is, much less be able to affect it?) Given
the code complexity of the USERLIMIT stuff and the number of bugs
already found in it, getting rid of it seems awfully attractive.

Without USERLIMIT, we could easily change the rules to make ALTER USER
work the way you want: we'd say you have to be superuser to issue ALTER
USER or ALTER DATABASE with a SUSET variable (already true), and then
the value can be adopted at session start in all cases since we can then
treat pg_shadow and pg_database as secure sources.

regards, tom lane