Bug 801995

Summary: [Feature Request] add base directory security (not allow bricks outside of specified base directory)
Product: [Community] GlusterFS Reporter: Robert Lanning <lanning>
Component: glusterdAssignee: krishnan parthasarathi <kparthas>
Status: CLOSED EOL QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: mainlineCC: bugs, gluster-bugs, nsathyan, rwheeler
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: All   
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-10-22 11:46:38 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Robert Lanning 2012-03-10 00:27:30 EST
Description of problem:
If a gluster server is broken into, attacker can access all other gluster servers via add-brick hostx:/

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:
There should be a config option for glusterd, to tell it a base directory(or directories) where bricks can reside.  Not allowing access to any other path.

Additional info:
Comment 1 Amar Tumballi 2012-12-26 00:56:56 EST
(with 3.4.0qa6)

[root@supernova ~]# gluster volume create junk ganaka:/
volume create: junk: failed: Unable to get brick info from brick ganaka:
[root@supernova ~]# gluster volume create junk ganaka:/data/export/junk
volume create: junk: success: please start the volume to access data
[root@supernova ~]# gluster volume add-brick junk ganaka:/
volume add-brick: failed: brick path ganaka: is too long

Well the 'error message' is not valid. But we don't have the risk of exporting '/' (root) itself any more. Hence reducing the priority of the bug.

But the suggestion about the feature is still valid, and I guess it makes sense to have this control.
Comment 2 Niels de Vos 2014-11-27 09:45:07 EST
Feature requests make most sense against the 'mainline' release, there is no ETA for an implementation and requests might get forgotten when filed against a particular version.
Comment 3 Kaleb KEITHLEY 2015-10-22 11:46:38 EDT
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.