On 25 March 2014 19:47, Andreas Hasenack <[email protected]> wrote: > On Tue, Mar 25, 2014 at 7:51 AM, Stuart Bishop <[email protected]> > wrote: > >> The simple fix is to add a usernames or extra_usernames parameter on >> the relation, similar to database, allowing the client to specify a >> list of extra usernames that should be allowed to connect from the >> client to this relation's database. > > This works, and has the benefit of using randomly generated passwords. > But I need these to be shared among different services, like mysql's > shared-db relation.
Right. You would need to specify the password too, and ensure they all match. >> There are security issues with this approach. A malicious client can >> specify a database and user with permissions, gaining access to >> another service's data. If service_a and service_b are related to the >> same PostgreSQL service, then if service_a is compromised then all of >> service_b's data is also accessible. > > This is the same as with mysql's shared-db relation, right? The same > risk exists there, as all services have access to each other's > credentials. I haven't looked at the implementation, and don't know enough about mysql's database level security to know if it matters. If a service can gain access to any database as any user it requests via the relation, then if it is compromised it can gain access to any database as any user. I'd rather not add that problem to the PostgreSQL charm if we can avoid it, or if someone more familiar with juju's internals can tell me it isn't possible or irrelevant. >> For your particular use case of patching the database, we could use >> the db-admin relation. This already connects as a superuser to any >> database, and we could open that up to connecting to any database as >> any user without lowering security further. > > The patch would be like: "GRANT DELETE ON TABLE person TO landscape". > That "landscape" is hardcoded, so that user has to exist and be the > user the services use. So your first paragraph above solves this > already, right? We give a list of users to postgresql via the > relation, and "landscape" is in that list. I see. If this is the issue, then the 'roles' feature already does what you need: 'relation-set roles=landscape' in your db-relation-joined hook, and the generated user will be granted the landscape role and inherit all its permissions (users and groups are now just roles in postgresql, 'user' and 'group' are just syntactic sugar and help make documentation more readable). This is the recommended way of handing database permissions, rather than granting them individually to all the login roles. -- Stuart Bishop <[email protected]> -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
