[Bugs] [Bug 1226220] [FEAT] directory level SSL/TLS auth

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1226220

Jeff Darcy <jdarcy at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |csaba at redhat.com,
                   |                            |jdarcy at redhat.com
              Flags|                            |needinfo?(csaba at redhat.com)



--- Comment #1 from Jeff Darcy <jdarcy at redhat.com> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.