Bug 974624 - remote-host switch allows an untrusted host to manage the trusted pool
Summary: remote-host switch allows an untrusted host to manage the trusted pool
Keywords:
Status: CLOSED EOL
Alias: None
Product: GlusterFS
Classification: Community
Component: cli
Version: 3.4.0-beta
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
Assignee: bugs@gluster.org
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-14 16:31 UTC by Joe Julian
Modified: 2015-10-08 14:48 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-07 14:05:55 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Joe Julian 2013-06-14 16:31:18 UTC
Description of problem:

This works:
client1# gluster --remote-host=server1 peer probe client1

which allows any host to add itself to the trusted peer group, or manage volumes, etc.

Actual results:
Any command is successful.

Expected results:
Untrusted hosts should not be trusted.

Workaround:
Use iptables to manage connectivity to the management port

Comment 1 John Smith 2013-06-23 18:58:46 UTC
'gluster --remote-host' is just insecure in its current implementation. There really is no need to even do a 'peer probe' first for malicious actions, when you can just do something like this :

gluster --remote-host=server1 volume info
gluster --remote-host=server1 volume stop myvol
gluster --remote-host=server1 volume delete myvol

No 'peer probe' needed.

Comment 2 Jeff Darcy 2013-07-05 13:54:08 UTC
*At the very least*, glusterd should restrict non-members to read-only operations (e.g. info, getspec).  More generally, we should fix any remaining issues that prevent using SSL for glusterd, and protect all connections to glusterd using SSL certificates.  If desired, we could implement a "bootstrap" process by which cluster members generate/acquire these certificates automatically, so the additional protection would be practically invisible to them.

Comment 3 Niels de Vos 2015-05-17 22:01:18 UTC
GlusterFS 3.7.0 has been released (http://www.gluster.org/pipermail/gluster-users/2015-May/021901.html), and the Gluster project maintains N-2 supported releases. The last two releases before 3.7 are still maintained, at the moment these are 3.6 and 3.5.

This bug has been filed against the 3,4 release, and will not get fixed in a 3.4 version any more. Please verify if newer versions are affected with the reported problem. If that is the case, update the bug with a note, and update the version if you can. In case updating the version is not possible, leave a comment in this bug report with the version you tested, and set the "Need additional information the selected bugs from" below the comment box to "bugs".

If there is no response by the end of the month, this bug will get automatically closed.

Comment 4 Kaleb KEITHLEY 2015-10-07 14:05:55 UTC
GlusterFS 3.4.x has reached end-of-life.

If this bug still exists in a later release please reopen this and change the version or open a new bug.


Note You need to log in before you can comment on or make changes to this bug.