Bug 801995 - [Feature Request] add base directory security (not allow bricks outside of specified base directory)
Summary: [Feature Request] add base directory security (not allow bricks outside of sp...
Keywords:
Status: CLOSED EOL
Alias: None
Product: GlusterFS
Classification: Community
Component: glusterd
Version: mainline
Hardware: All
OS: All
medium
medium
Target Milestone: ---
Assignee: krishnan parthasarathi
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-10 05:27 UTC by Robert Lanning
Modified: 2015-11-03 23:06 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-22 15:46:38 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

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.


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