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:	glusterd	Assignee:	krishnan parthasarathi <kparthas>
Status:	CLOSED EOL	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	mainline	CC:	bugs, gluster-bugs, nsathyan, rwheeler
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-10-22 15:46:38 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Robert Lanning 2012-03-10 05:27:30 UTC

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:
1.
2.
3.
  
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 05:56:56 UTC

(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 14:45:07 UTC

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 15:46:38 UTC

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.