Still a loose end in GUC USERLIMIT stuff

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Still a loose end in GUC USERLIMIT stuff
Date: 2004-08-31 19:42:41
Message-ID: 14345.1093981361@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

As of CVS tip, an increase in a USERLIMIT parameter in postgresql.conf
will be enforced against the sessions of superusers as well as everyone
else. That's because I ifdef'd out this code:

/*
* If user is a superuser, he gets to keep his setting. We can't check
* this unless inside a transaction, though. XXX in practice that
* restriction means this code is essentially worthless, because the
* result will depend on whether we happen to be inside a transaction
* block when SIGHUP arrives. Dike out until we can think of something
* that actually works.
*/
#ifdef NOT_USED
if (IsTransactionState() && superuser())
return false;
#endif

It'd be better if it worked as originally intended, but this code cannot
be made to do that with any reliability.

The superuser() test has another problem besides what I mentioned in the
comment, which is that its result will vary depending on SET SESSION
AUTHORIZATION, SECURITY INVOKER function calls, and so on; so it might
return an indication that has nothing to do with the privileges that
were used when the GUC variable was set.

Offhand the only reasonable way I can see to handle this is that *when a
setting is made* we set a flag bit on the GUC variable showing whether
it was set by a superuser or not, and then check that flag rather than
the current superuser state when deciding whether to override the value.
I am not sure it's really worth the trouble though. Also this would not
be exactly the original coding intention, I think, because the original
code attempted to protect the superuser's effective setting whether he
had explicitly set the value or just inherited it from postgresql.conf.

Comments?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Serguei A. Mokhov 2004-08-31 20:13:38 Resurrecting pg_upgrade
Previous Message Bruce Momjian 2004-08-31 18:57:28 Re: [PATCHES] ALTER SCHEMA ... SET TABLESPACE