Bug 1329945 - vmdb_production schema is public
Summary: vmdb_production schema is public
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.5.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: GA
: 5.6.0
Assignee: Nick Carboni
QA Contact: Dave Johnson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-25 07:30 UTC by Eduardo Minguez
Modified: 2017-12-05 15:46 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-26 13:18:06 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:


Attachments (Terms of Use)

Description Eduardo Minguez 2016-04-25 07:30:10 UTC
Description of problem: vmdb_production schema is public


Version-Release number of selected component (if applicable):


How reproducible:

As pgsql user:

postgres=# \c vmdb_production
You are now connected to database "vmdb_production" as user "postgres".
vmdb_production=# \dS
                                   List of relations
   Schema   |                        Name                        |   Type   |  Owner
------------+----------------------------------------------------+----------+----------
...
 public     | accounts                                           | table    | root
 public     | accounts_id_seq                                    | sequence | root
 public     | advanced_settings                                  | table    | root
 public     | advanced_settings_id_seq                           | sequence | root
...

Even show data inside the database (select * from users;)

Is this a design decision? Can this be "hardened"?


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:
It would be nice to have this extra "security" stuff enabled (AFAIK (or read) it seems pretty simple to avoid http://stackoverflow.com/a/13087493)

Additional info:

Comment 2 Nick Carboni 2016-04-25 13:18:09 UTC
I'm not sure I understand the issue.

We run the database internal to the appliance and only expect to be hosting one database on the cluster in production (vmdb_production). Because of this we only create one database user and use that user for most (if not all) operations.

What are you doing where you are creating additional database users that should not have access to the vmdb_production database?

Comment 3 Eduardo Minguez 2016-04-26 06:59:10 UTC
(In reply to Nick Carboni from comment #2)
> I'm not sure I understand the issue.
> 
> We run the database internal to the appliance and only expect to be hosting
> one database on the cluster in production (vmdb_production). Because of this
> we only create one database user and use that user for most (if not all)
> operations.
> 

I agree that works, but wouldn't be better to have it secured by default?


> What are you doing where you are creating additional database users that
> should not have access to the vmdb_production database?

IHAC thinking about creating some process to query the CFME database to fed an elasticsearch cluster when they found this.

HTH

Comment 4 Nick Carboni 2016-04-26 13:18:06 UTC
The issue is that there is nothing to be "secured" even if we change the schema, the issue referenced in the stackoverflow link is about what permissions should be set for schemas in *new* databases, the issue the poster is having is that they want to explicitly grant any new privileges needed when creating a new database rather than having some users which will have permissions be default.  

Because we only have one database, one schema, and one user which should be able to access everything in that database, this is not something we have to worry about.

Even your suggested use case can connect to the database as the root user with the password that was chosen using the appliance_console when the database was created.

If you require more strict permissions for your use case you can create a new database user and revoke some permissions from your new user on the database vmdb_production or the public schema.

See the postgres documentation for more detail (http://www.postgresql.org/docs/9.4/static/ddl-schemas.html)

Closing this as NOTABUG


Note You need to log in before you can comment on or make changes to this bug.