Bug 1226220 - [RFE] directory level SSL/TLS auth
Summary: [RFE] directory level SSL/TLS auth
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: GlusterFS
Classification: Community
Component: core
Version: mainline
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Csaba Henk
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-29 08:53 UTC by Csaba Henk
Modified: 2017-09-05 13:46 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-05 13:46:00 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Csaba Henk 2015-05-29 08:53:25 UTC
Description of problem:

Configuring and performing SSL/TLS authentication and authorization should be possible at the directory level.

Comment 1 Jeff Darcy 2015-05-29 12:19:34 UTC
This is way too complex to design on the fly.  Please provide a link to a design or feature page when one is available.  I'll help by describing some of the constraints that apply.

(1) Any given connection can have only one set of TLS credentials.

(2) Those credentials are needed during the initial connection setup, i.e. before any operations that might be used to select (or even find) a subdirectory.

(3) There needs to be a well defined UI (CLI + other) to manage multiple credentials and their mapping to specific subdirectories.

(4) There must be strong protections in place to prevent a connection established with one set of credentials from "escaping" to a different directory protected by a different set of credentials.

I strongly suggest that we support separate credentials only for top-level directories within a volume, not arbitrary levels down and certainly not nested within each other.  The subdirectory and matching credentials can most easily be provided as a mount option.  You'll need code in both rpc-transport/socket and protocol/server to process that option, in the latter case by binding each connection to a separate inode table with the root inode remapped to the specified subdirectory.  There might be other places where the meaning of "root inode" needs to be modified to account for this remapping.

There are probably other interactions (e.g. with quota and snapshots) that need to be considered.

Comment 2 Csaba Henk 2017-09-05 13:46:00 UTC
The efforts to address this problem will be tracked at https://github.com/gluster/glusterfs/issues/317.


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