Thread: Why is lc_messages superuser only?

Looking around the lc_messages stuff a bit, I notice it's set to
superuser-only. 

I do use
ALTER USER joe SET lc_messages='sv_SE'

now and then to change the language for a user. And I see it's also
possible to use it on a database level by doing
ALTER DATABASE postgres SET lc_messages='sv_SE'

(user overriding database overriding system default, as expected)

However, it can also be useful for the user to be able to change his own
session, and this only works if you are superuser.

Is there a reason for this?

//Magnus

Magnus Hagander wrote:
> Looking around the lc_messages stuff a bit, I notice it's set to
> superuser-only. 
>
> I do use
> ALTER USER joe SET lc_messages='sv_SE'
>
> now and then to change the language for a user. And I see it's also
> possible to use it on a database level by doing
> ALTER DATABASE postgres SET lc_messages='sv_SE'
>
> (user overriding database overriding system default, as expected)
>
> However, it can also be useful for the user to be able to change his own
> session, and this only works if you are superuser.
>
> Is there a reason for this?
>
>
>   

Presumably we don't want a user changing what is used on the logs ...

cheers

andrew

Magnus Hagander <magnus@hagander.net> writes:
> Is there a reason for this?

Two arguments I can recall:

(1) Having log messages emitted in a language that the DBA can't read
would be a useful tactic for a Bad Guy trying to cover his tracks.

(2) Setting lc_messages to a value incompatible with the database
encoding would be likely to result in PANIC or worse.

If we had more-robust locale support, I could see separating lc_messages
into one setting for messages bound to the client and one for messages
bound to the log, and making the latter superuser only (or, more likely,
PGC_SIGHUP, because surely you'd want DB-wide consistency).  But we
are nowhere near being able to do that.
        regards, tom lane

It is so that the user cannot "hide" log messages he causes by setting the 
language to something that the administrator cannot understand.  (There are 
more conceivable scenarios of that sort, such as exploiting the 
administrator's ad hoc log parsing tool.)

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Mon, Jul 23, 2007 at 11:20:15AM -0400, Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
> > Is there a reason for this?
> 
> Two arguments I can recall:
> 
> (1) Having log messages emitted in a language that the DBA can't read
> would be a useful tactic for a Bad Guy trying to cover his tracks.
> 
> (2) Setting lc_messages to a value incompatible with the database
> encoding would be likely to result in PANIC or worse.
> 
> If we had more-robust locale support, I could see separating lc_messages
> into one setting for messages bound to the client and one for messages
> bound to the log, and making the latter superuser only (or, more likely,
> PGC_SIGHUP, because surely you'd want DB-wide consistency).  But we
> are nowhere near being able to do that.

Ok. That makes a lot of sense, unfortunately. Hopefully something we can
get sometime in the future, then :-)

//Magnus