Re: Client Messages - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Client Messages
Date
Msg-id 4F167E08.9030802@enterprisedb.com
Whole thread Raw
In response to Re: Client Messages  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Client Messages
List pgsql-hackers
On 18.01.2012 07:49, Fujii Masao wrote:
> On Fri, Jan 6, 2012 at 1:38 AM, Jim Mlodgenski<jimmy76@gmail.com>  wrote:
>> I have a need to send banner messages to a psql client that I can set
>> on the server and will be displayed on any psql client that connects
>> to the database. This would be mostly used as an additional indicator
>> to which database you are connecting, but could also be used by people
>> to force their users to see an security message when connecting to the
>> database. The attached patch will allow you to execute
>>
>> ALTER DATABASE postgres SET
>> client_message=E'********************************************************************************\nBEWARE:
>> You are connecting to a production database. If you do anything to\n
>>      bring this server down, you will be destroyed by your supreme
>> overlord.\n********************************************************************************\n';
>>
>> And then when you connect to psql, you will see:
>>
>> [e3@workstation bin]$ ./psql -U user1 postgres
>> psql (9.2devel)
>> ********************************************************************************
>> BEWARE: You are connecting to a production database. If you do anything to
>>         bring this server down, you will be destroyed by your supreme overlord.
>> ********************************************************************************
>>
>> Type "help" for help.
>>
>> postgres=>
>>
>>
>> Any feedback is welcome.
>
> Adding new GUC parameter only for the purpose of warning psql users
> seems overkill to me.  Basically we try to reduce the number of GUC
> parameters to make a configuration easier to a user, so I don't think that
> it's good idea to add new GUC for such a small benefit.

It seems quite useful to me...

> Instead, how
> about using .psqlrc file and writing a warning message in it by using
> \echo command?

That's not the same thing at all. Each client would need to put the 
warning in that file, and you'd get it regardless of the database you 
connect to.

> Anyway, I found one problem in the patch. The patch defines client_message
> as PGC_USERSET parameter, which means that any psql can falsify a
> warning message, e.g., by setting the environment variable PGOPTIONS
> to "-c client_message=hoge". This seems to be something to avoid from
> security point of view.

I don't think that's a problem, it's just a free-form message to 
display. But it also doesn't seem very useful to have it PGC_USERSET: if 
it's only displayed at connect time, there's no point in changing it 
after connecting.

The only security problem that I can think of is a malicious server 
(man-in-the-middle perhaps), that sends a banner that confuses

Docs for PQparameterStatus() needs adjustment, now that client_message 
is also one of the settings automatically reported to the client.

The placement of the banner in psql looks currently like this:
> $ psql postgres
> psql (9.2devel)
> Hello world!
> Type "help" for help.

or

> postgres=# \c postgres
> Hello world!
> You are now connected to database "postgres" as user "heikki".

Are we happy with that? I think it would be better to print the banner 
just before the prompt:

> psql (9.2devel)
> Type "help" for help.
>
> Hello world!
>
> postgres=# \c postgres
> You are now connected to database "postgres" as user "heikki".> Hello world!> postgres=#

Should we prefix the banner with something that makes it clear that it's 
a message coming from the server? Something like:
> psql (9.2devel)> Type "help" for help.>> Notice from server: Hello world!>> postgres=# \c postgres> You are now
connectedto database "postgres" as user "heikki".> Notice from server: Hello world!> postgres=#
 

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: WIP patch for parameterized inner paths
Next
From: Dimitri Fontaine
Date:
Subject: Re: Command Triggers