Re: Proposed patch to remove USERLIMIT

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Tom Lane wrote:
> >> started because setting these variables via ALTER USER fails to work.
>
> > It fails to work if logging was already on and someone wants to turn it
> > off via ALTER USER, and that matches the expected behavior.
>
> Not if a superuser does it; superusers should be allowed to set it
> however they want. In current code a superuser can't even set it
> that way for himself, let alone for other nonprivileged users.
> You seem to define "expected behavior" as "whatever the code does now",
> but in point of fact it's got lots of deficiencies.

I just turned logging on in my postgresql.conf file, did as super-user:

test=> ALTER USER postgres SET log_statement = 'none';

and it seemed to work fine. Are you saying the problem is that the
super-user can't set log_statement for non-super users via ALTER USER?
Yes, that doesn't work, but I have seen only one user request to do
that, while I have seen a lot of requests of people wanting to turn
log_statement on and off as non-super users in their applications.

> > Well, you have just made the system less secure by creating that
> > function. Why didn't you create a function that has the existing
> > behavior of only allowing users to increase the log level?
>
> I repeat my point: I don't think DBAs actually need that. In the
> function as illustrated, I gave joe_user (and nobody else) the choice
> between 'all' and 'ddl' (and nothing else), where I suppose 'ddl' is the
> global default. This is in fact a whole lot *more* secure than the
> existing behavior, in the sense that I can constrain what's allowed a
> lot more.
>
> If I later decide I want 'mod' as the global default, I can alter the
> function to map it that way, and joe_user's application is entirely
> unaffected. This is *not* true if I expect joe_user's app to set the
> variable directly. He has to go change his app to conform to the new
> global default.

OK, so you are saying your function has to be aligned with the global
default.

> >> think so. I think that in the field, people are going to have at most
> >> a couple of logging configurations they want to allow users to select,
> >> and they will use code not significantly more complex than the above.
>
> > Can you show me the function?
>
> I did.

I want to see one that allows a non-super user to only to increase the
log level without predefining the lowest log level allowed.

> > You should ask on general where
> > we usually do such polls of feature changes?
>
> Where was the poll in which we decided that the logging variables needed
> to be secured at all? In 7.3 these variables were all plain USERSET.

We didn't need a pool because we had repeated user complaints stating
our current setup was insecure, and we weren't in feature freeze or near
final release.

This whole discussion is taking time away from getting us to final.

--
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