Sean Chittenden <[EMAIL PROTECTED]> writes:
> doh! So much for that idea. There's no real way to have some
> useconfig variables run by the super user and some run by the session
> user. My workaround is to have the program call a SECURITY DEFINER
> function, but I'd be nice to be able to remove that hack.
Yeah, the whole concept of USERLIMIT GUC variables is fairly dubious,
because of the fact that we have to be able to set these values at times
when we don't necessarily know whether the user is a superuser or not.
It occurs to me though that we might be able to handle this one case.
Variable values coming from ALTER USER/DATABASE SET ... are currently
treated as untrusted (because of the ordering of enum GucSource).
However, we *also* test whether the user executing the ALTER has
permissions:
regression=> ALTER USER tgl SET log_duration = false;
ERROR: permission denied to set parameter "log_duration"
HINT: Must be superuser to change this value to false.
At first glance it seems like the ALTER-time test is a sufficient
security check and therefore PGC_S_DATABASE and PGC_S_USER sources
could be treated as privileged.
This doesn't entirely work, because the USERLIMIT checks are context
sensitive: if the current config-file setting of log_duration is FALSE
then I will be allowed to install the above per-user setting, and
without the time-of-use check it would override any change in the global
setting that the DBA tried to make.
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.
Comments?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
