|Summary:||Basic security for glusterd|
|Product:||[Community] GlusterFS||Reporter:||Jeff Darcy <jdarcy>|
|Status:||CLOSED EOL||QA Contact:|
|Version:||mainline||CC:||bugs, gluster-bugs, ndevos, pportant, rwheeler, zaitcev|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-10-22 15:46:38 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Jeff Darcy 2012-11-26 14:59:14 UTC
This started with the discussion on http://review.gluster.org/#change,4231 which proposes a new use of the gluster CLI from non-servers. I also have some scripts that use the same --remote-host hook. The problem is that glusterd is still utterly, totally, trusting. Anyone who can connect to the port can issue any command, including those that are often hard to recover from even when used properly. Relying on firewalls to block access to the glusterd port is just too weak to consider, and allowed-host lists aren't much better (especially without any reasonable way to manage either). We don't need full role-based access control, but we do need *some* reasonable login-level control. Our two main options are SSL and username/password. Both exist at the transport layer, though SSL currently only does authentication without authorization so something like http://review.gluster.org/#change,3695 would be necessary. Either way, the servers can be pre-provisioned with the right credentials (e.g. propagated as part of the "peer probe" process) so they wouldn't notice anything different when communicating among themselves. All we really need is some way to extend those credentials to another trusted machine that isn't a server, and possibly some way to modify the passwords/certificates. NB: This is not the same as bug 765359, which has to do with *local* CLI access. Obviously they're related, though. This one's almost a superset, in the sense that if we resolve this then we pretty much automatically resolve the other as well.
Comment 1 Amar Tumballi 2013-01-07 10:40:38 UTC
Even though, not having proper security policy is 'bug', would like to call it as Feature Future, as there is surely 'enhancement' like work involved for this.
Comment 2 Kaleb KEITHLEY 2015-10-22 15:46:38 UTC
because of the large number of bugs filed against mainline version\ is ambiguous and about to be removed as a choice. If you believe this is still a bug, please change the status back to NEW and choose the appropriate, applicable version for it.