Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1179208

Summary:	Since 3.6; ssl without auth.ssl-allow broken
Product:	[Community] GlusterFS	Reporter:	bugzilla.redhat.com
Component:	transport	Assignee:	Jeff Darcy <jdarcy>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	high	Docs Contact:
Priority:	medium
Version:	mainline	CC:	bugs, dshetty, gluster-bugs, howey.vernon, jdarcy
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	glusterfs-3.7.0	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-05-14 17:28:51 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:
Embargoed:

Description bugzilla.redhat.com 2015-01-06 12:43:12 UTC

Description of problem:

I upgraded to 3.6.1 recently; and all my clients broke. It turned out this was caused by the "improved ssl support"; which uses ssl-allow to determine if a user is allowed to connect.

Previously any client with a valid certificate was allowed; but now auth.ssl-allow '*' is required. Without it, all clients will log:

I [socket.c:379:ssl_setup_connection] 0-volume-client-0: peer CN = fs1.xxx
I [client-handshake.c:1415:select_server_supported_programs] 0-volume-client-0: Using Program GlusterFS 3.3, Num (1298437), Version (330)
W [client-handshake.c:1109:client_setvolume_cbk] 0-volume-client-0: failed to set the volume (Permission denied)
W [client-handshake.c:1135:client_setvolume_cbk] 0-volume-client-0: failed to get 'process-uuid' from reply dict
E [client-handshake.c:1141:client_setvolume_cbk] 0-volume-client-0: SETVOLUME on remote-host failed: Authentication failed
I [client-handshake.c:1227:client_setvolume_cbk] 0-volume-client-0: sending AUTH_FAILED event
E [fuse-bridge.c:5145:notify] 0-fuse: Server authenication failed. Shutting down.

This is fixed by adding auth.ssl-allow='*'. Additionally; it seems wildcards aren't fully supported. I initially tried *.valid-domain.tld and gluster says:

E [server.c:416:_check_for_auth_option] 0-/export/volume: internet address '*.valid-domain.tld' does not conform to standards.
E [server.c:449:validate_auth_options] 0-volumes-server: volume '/export/volume' defined as subvolume, but no authentication defined for the same
E [xlator.c:425:xlator_init] 0-volume-server: Initialization of volume 'volume-server' failed, review your volfile again
E [graph.c:322:glusterfs_graph_init] 0-volume-server: initializing translator failed
E [graph.c:525:glusterfs_graph_activate] 0-graph: init failed
W [glusterfsd.c:1194:cleanup_and_exit] (--> 0-: received signum (0), shutting down

Issues:
* BUG:  ssl-allow should default to '*' like allow does
* FEAT: *.domain should work for ssl-allow
* FEAT: The "Permission denied" message should indicate which module threw AUTH_REJECT

Comment 1 Anand Avati 2015-01-06 16:34:35 UTC

REVIEW: http://review.gluster.org/9397 (transport: fix default behavior for SSL authorization) posted (#1) for review on master by Jeff Darcy (jdarcy)

Comment 2 Jeff Darcy 2015-01-06 16:41:22 UTC

The posted patch addresses the default behavior (equivalent to an explicit ssl-allow=*).  It also skips the misguided validation of a username as a host name or IP address (the _check_for_auth_option error).

It does *not* address the other two feature requests.  In particular, domain wildcards don't make much sense because the identities involved are of *users* rather than hosts.  Username wildcards do work, and this is now part of the regression test.  For host/domain wildcards, there is underlying support for an "auth.addr.*.allow" volume option, but it's not clear how well exposed that is through the CLI.

Comment 3 Jeff Darcy 2015-01-06 17:05:07 UTC

This bug exists in master.  It's more important to fix it there than in a 3.6-specific branch where a workaround already exists.

Comment 4 Anand Avati 2015-01-06 17:09:14 UTC

REVIEW: http://review.gluster.org/9397 (transport: fix default behavior for SSL authorization) posted (#2) for review on master by Jeff Darcy (jdarcy)

Comment 5 Anand Avati 2015-01-06 17:09:38 UTC

REVIEW: http://review.gluster.org/9397 (transport: fix default behavior for SSL authorization) posted (#3) for review on master by Jeff Darcy (jdarcy)

Comment 6 bugzilla.redhat.com 2015-01-07 10:30:21 UTC

(In reply to Jeff Darcy from comment #2)
> It does *not* address the other two feature requests.  In particular, domain
> wildcards don't make much sense because the identities involved are of
> *users* rather than hosts.  Username wildcards do work, and this is now part
> of the regression test.  For host/domain wildcards, there is underlying
> support for an "auth.addr.*.allow" volume option, but it's not clear how
> well exposed that is through the CLI.

That makes sense; I actually use machine-names in my certificates; since the CN is passed as a username and you removed the bogus validation this feature will probably be fixed for me as well. Thanks for the quick fix!

Comment 7 Anand Avati 2015-01-09 18:04:16 UTC

COMMIT: http://review.gluster.org/9397 committed in master by Vijay Bellur (vbellur) 
------
commit 548547b2e41c8e2cf79b929405cf18aecbdedebc
Author: Jeff Darcy <jdarcy>
Date:   Tue Jan 6 10:03:49 2015 -0500

    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>
    Reviewed-on: http://review.gluster.org/9397
    Reviewed-by: Krishnan Parthasarathi <kparthas>
    Tested-by: Gluster Build System <jenkins.com>
    Reviewed-by: Vijay Bellur <vbellur>

Comment 8 Niels de Vos 2015-05-14 17:28:51 UTC

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.0, please open a new bug report.

glusterfs-3.7.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user

Comment 9 Niels de Vos 2015-05-14 17:35:47 UTC

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.0, please open a new bug report.

glusterfs-3.7.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user

Comment 10 Niels de Vos 2015-05-14 17:38:09 UTC

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.0, please open a new bug report.

glusterfs-3.7.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user

Comment 11 Niels de Vos 2015-05-14 17:45:36 UTC

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.0, please open a new bug report.

glusterfs-3.7.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user