Bug 801995 - [Feature Request] add base directory security (not allow bricks outside of specified base directory)
[Feature Request] add base directory security (not allow bricks outside of sp...
Product: GlusterFS
Classification: Community
Component: glusterd (Show other bugs)
All All
medium Severity medium
: ---
: ---
Assigned To: krishnan parthasarathi
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2012-03-10 00:27 EST by Robert Lanning
Modified: 2015-11-03 18:06 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-10-22 11:46:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
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.

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