transport: fix default behavior for SSL authorization

Previously, enabling SSL authentication/encryption but not authorization
required explicitly setting ssl-allow=*.  Now that same behavior is the
default (i.e. when ssl-allow is not set).

Also, there's no reason that a name used for *login* auth (typically a
UUID for internal purposes or a human name when using SSL) should
validate as an RFC-compliant host name or IP address.  Therefore the
validation only occurs when the auth type is "addr" (not "login" or
anything else).

Change-Id: I01485ff4f0ab37de4b182858235a5fb0cf4c3c7d
BUG: 1179208
Signed-off-by: Jeff Darcy <jdarcy@redhat.com>
Reviewed-on: http://review.gluster.org/9397
Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>

1 files changed, 22 insertions, 1 deletions

diff --git a/xlators/protocol/auth/login/src/login.c b/xlators/protocol/auth/login/src/login.c
index 56b93a9f9e9..b53c5ccba21 100644
--- a/xlators/protocol/auth/login/src/login.c
+++ b/xlators/protocol/auth/login/src/login.c
@@ -38,7 +38,6 @@ auth_result_t gf_auth (dict_t *input_params, dict_t *config_params)
                 gf_log ("auth/login", GF_LOG_INFO,
                         "connecting user name: %s", username_data->data);
                 using_ssl = _gf_true;
-                result = AUTH_REJECT;
         }
         else {
                 username_data = dict_get (input_params, "username");
@@ -80,6 +79,28 @@ auth_result_t gf_auth (dict_t *input_params, dict_t *config_params)
         if (allow_user) {
                 gf_log ("auth/login", GF_LOG_INFO,
                         "allowed user names: %s", allow_user->data);
+                /*
+                 * There's a subtle difference between SSL and non-SSL behavior
+                 * if we can't match anything in the "while" loop below.
+                 * Intuitively, we should AUTH_REJECT if there's no match.
+                 * However, existing code depends on allowing untrusted users
+                 * to connect with *no credentials at all* by falling through
+                 * the loop.  They're still distinguished from trusted users
+                 * who do provide a valid username and password (in fact that's
+                 * pretty much the only thing we use non-SSL login auth for),
+                 * but they are allowed to connect.  It's wrong, but it's not
+                 * worth changing elsewhere.  Therefore, we do the sane thing
+                 * only for SSL here.
+                 *
+                 * For SSL, if there's a list *you must be on it*.  Note that
+                 * if there's no list we don't care.  In that case (and the
+                 * ssl-allow=* case as well) authorization is effectively
+                 * disabled, though authentication and encryption are still
+                 * active.
+                 */
+                if (using_ssl) {
+                        result = AUTH_REJECT;
+                }
                 username_cpy = gf_strdup (allow_user->data);
                 if (!username_cpy)
                         goto out;