Bug 1198746

GlusterFS supports a concept of a trusted or privileged mount.  Usually, unless someone has hacked volfiles by hand, users can connect to bricks without any credentials at all.  However, if they do use a matching username and password set when the volume is created, they are allowed to bypass the "root squashing" that is normally done to ensure that uid/gid checks are performed properly.  This feature is used by some internal daemons.

Unfortunately, this password is both stored and transmitted in plaintext (unless TLS is explicitly enabled for the control path as well as data).  The following command run from any host (as root on that host) will suffice to reveal it.

   gluster --remote-host=a_server system getspec a_volume

Note that this behavior only exists with the "remote-host" option; a local (UNIX-domain socket) fetch will get the same volfile but without the username and password.  Fixing __server_getspec (specifically line 766 of glusterd-handshake.c) to provide the username/password only via the UNIX-domain socket, and fixing the internal daemons to use that method, would fix the worst vulnerability.  However, this would still fall short in environments (e.g. converged storage/compute) where users running on the same machine as glusterd might still be able to access the UNIX-domain socket.  We should probably devise more secure mechanism by which to distinguish internal daemons from "outsiders" and possibly to distinguish password holders from others (without storing or transmitting that password in plaintext).