| Summary: | vmdb_production schema is public | ||
|---|---|---|---|
| Product: | Red Hat CloudForms Management Engine | Reporter: | Eduardo Minguez <eminguez> |
| Component: | Appliance | Assignee: | Nick Carboni <ncarboni> |
| Status: | CLOSED NOTABUG | QA Contact: | Dave Johnson <dajohnso> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 5.5.0 | CC: | abellott, eminguez, jhardy, ncarboni, obarenbo |
| Target Milestone: | GA | ||
| Target Release: | 5.6.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-04-26 13:18:06 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
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? (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 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 |
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: