Re: Proposed patch to remove USERLIMIT - Mailing list pgsql-patches
From | Bruce Momjian |
---|---|
Subject | Re: Proposed patch to remove USERLIMIT |
Date | |
Msg-id | 200411111627.iABGRxn22594@candle.pha.pa.us Whole thread Raw |
In response to | Re: Proposed patch to remove USERLIMIT (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Proposed patch to remove USERLIMIT
|
List | pgsql-patches |
The bottom line is that I have no problem with making this change, but I want to be sure it is a full solution we aren't going to have to revisit later. I don't want to make the change and then find out we rushed it and have to make more adjustments in later releases. --------------------------------------------------------------------------- Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.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. > > > 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. > > >> 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. > > > 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. > > regards, tom lane > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
pgsql-patches by date: