From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bertrand Petit <pgsql-bugs(at)phoe(dot)frmug(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Subject: | Re: [BUGS] 7.4 beta 1: SET log_statement=false |
Date: | 2003-08-13 22:05:46 |
Message-ID: | 200308132205.h7DM5kT09845@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers pgsql-patches |
[ Moved to hackers.]
Tom Lane wrote:
> Bertrand Petit <pgsql-bugs(at)phoe(dot)frmug(dot)org> writes:
> > Non superusers can set log_statement to true but can't set it
> > back to false even if log_statement was false at the begining of a
> > connection.
>
> Yeah. I think that the restrictions for USERLIMIT variables ought to
> compare against the reset_val, not the session_val.
I wish reset_val would fix it. This is the code being used:
/* Limit non-superuser changes */
if (record->context == PGC_USERLIMIT &&
source > PGC_S_UNPRIVILEGED &&
newval < conf->session_val &&
!superuser())
{
ereport(elevel,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
errmsg("permission denied to set option \"%s\"",
name),
errhint("Must be superuser to change this value to false.")));
return false;
}
It basically says:
o is this a USERLIMIT variable (restrict non-super users)
o is the new value being set in a user-accessible way
o is the value being set to true from false
o is this person not a super-user
I tried adding this line:
record->session_source < PGC_S_UNPRIVILEGED &&
and it does allow you to set the variable to false if you have set it to
true in your session, but it also allows you to set it to false if it is
set to true in postgresql.conf. You do this by setting it to 'true'
_then_ to 'false' in your session. The reason this works is that there
is no history in the GUC code to record the value this variable was set
at various locations. Once you set it to 'true' in your session, the
system remembers that, and forgets it was also set to true in
postgresql.conf, and therefore allows you to set it to false.
The documentation is vague on this point. It says:
Only superusers can turn off this option if it is enabled by
the administrator.
I think I should remove the part about administrators, and just say:
Only superusers can turn off this option.
or is that worse? The administrator part makes it clear why you
shouldn't be able to set it to false.
Peter, do you have any ideas on this?
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-08-13 22:29:33 | Re: [BUGS] 7.4 beta 1: SET log_statement=false |
Previous Message | Tom Lane | 2003-08-13 19:27:30 | Re: 7.4 beta 1: SET log_statement=false |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-08-13 22:29:33 | Re: [BUGS] 7.4 beta 1: SET log_statement=false |
Previous Message | Rod Taylor | 2003-08-13 21:55:12 | 7.4 beta1 plpgsql regression |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-08-13 22:29:33 | Re: [BUGS] 7.4 beta 1: SET log_statement=false |
Previous Message | Andrew Dunstan | 2003-08-13 21:07:46 | logging enhancements, minor code cleanup (retry) |