GRANT USAGE on FOREIGN SERVER exposes passwords

Поиск
Список
Период
Сортировка
От Noah Yetter
Тема GRANT USAGE on FOREIGN SERVER exposes passwords
Дата
Msg-id CAPuoA+k+aq68kF4y5k6=OWMx0wqq5+ZoO3i7uTmC1oV8Thkr_w@mail.gmail.com
обсуждение исходный текст
Ответы Re: GRANT USAGE on FOREIGN SERVER exposes passwords
Список pgsql-hackers
When a user is granted USAGE on a foreign server, the psql command \deu+ will show them the username and password bound to the applicable user mapping.

To demonstrate (9.3+):
(as a superuser)
# create extension postgres_fdw ;

# create foreign server loopback_server 
foreign data wrapper postgres_fdw 
options(host '127.0.0.1', port '5432') ;

# create user mapping for public 
server loopback_server
options(username 'foo', password 'bar') ;

(as a normal user)
> \deu+
                List of user mappings
        Server         | User name |  FDW Options
-----------------------+-----------+----------------
 loopback_server       | public    |
(1 row)

So far so good?

> select * from dblink('loopback_server', 'select current_date') as x(column1 date) ;
ERROR:  permission denied for foreign server loopback_server

OK, I can't do that now.  Let's fix it:

# grant usage on foreign server loopback_server to public ;

> select * from dblink('loopback_server', 'select current_date') as x(column1 date) ;
  column1
------------
 2015-02-03
(1 row)

Sweet!  But...

> \deu+
                      List of user mappings
        Server         | User name |          FDW Options
-----------------------+-----------+--------------------------------
 loopback_server       | public    | ("user" 'foo', password 'bar')
(1 row)

Crap.

(FWIW, it doesn't matter whether you grant to PUBLIC or to a specific user, the result is the same.)

The obvious objection is, "well you should just use foreign tables instead of dblink()".  I'll cut a long story short by saying that doesn't work for us.  We are using postgres_fdw to allow our analysts to run queries against AWS Redshift and blend those results with tables in our OLTP schema.  If you know anything about Redshift, or about analysts, you'll realize immediately why foreign tables are not a viable solution.  Surely there are many others in a similar position, where the flexibility offered by dblink() makes it preferable to fixed foreign tables.

Soooo... what gives?  This seems like a really obvious security hole.  I've searched the mailing list archives repeatedly and found zero discussion of this issue.


--
Noah Yetter
Data Architect/DBA @ Craftsy

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Process 'die' interrupts while reading/writing from the client s
Следующее
От: David Steele
Дата:
Сообщение: Re: Fwd: [GENERAL] 4B row limit for CLOB tables