Project

General

Profile

Cephfs - multitenancy features » History » Version 1

Jessica Mack, 07/06/2015 09:58 PM

1 1 Jessica Mack
h1. Cephfs - multitenancy features
2 1 Jessica Mack
3 1 Jessica Mack
h3. Summary
4 1 Jessica Mack
5 1 Jessica Mack
Make CephFS more secure in multi-tenant environments
6 1 Jessica Mack
7 1 Jessica Mack
h3. Owners
8 1 Jessica Mack
9 1 Jessica Mack
* Sage Weil (Red Hat)
10 1 Jessica Mack
* Name (Affiliation)
11 1 Jessica Mack
* Name
12 1 Jessica Mack
13 1 Jessica Mack
h3. Interested Parties
14 1 Jessica Mack
15 1 Jessica Mack
* Danny Al-Gaaf (Deutsche Telekom)
16 1 Jessica Mack
* Name (Affiliation)
17 1 Jessica Mack
* Name
18 1 Jessica Mack
19 1 Jessica Mack
h3. Current Status
20 1 Jessica Mack
21 1 Jessica Mack
CephFS has a capability defined that is intended to describe what a client is allowed to do.  Currently it parses a bunch fo stuff but we only interpret it as a binary value: is this client allowed to mount the file system?  If it mounts, it can do anything.
22 1 Jessica Mack
Ceph has similar capabilities that let you lock a client into different rados pools or rados namespaces.
23 1 Jessica Mack
CephFS lets you set a policy on a directory that puts new files in specific rados pools.
24 1 Jessica Mack
25 1 Jessica Mack
h3. Detailed Description
26 1 Jessica Mack
27 1 Jessica Mack
*Read-only mount*
28 1 Jessica Mack
Make the capability specify that a given client can only mount read-only and cannot make any cahnges
29 1 Jessica Mack
 
30 1 Jessica Mack
*Root squash*
31 1 Jessica Mack
Make the capability specify that a given client cannot act as root.  This should mimic the NFS semantics.  I went hunting for a detailed technical description of what that is, but didn't find anything.  Reading the source is probably the best way to establish that.  I think it means:
32 1 Jessica Mack
33 1 Jessica Mack
p((. cannot read/write/etc a file that is only readable/writeable/etc by root
34 1 Jessica Mack
35 1 Jessica Mack
Since the cephfs client is trusted to map ops to users, anything non-root is still fair game since the client can claim to be whatever uid/gid own the file.  I don't think it is worth trying anything else clever there... at least not until we specify in teh capability that we can only be a specific uid.  
36 1 Jessica Mack
 
37 1 Jessica Mack
*Path-based mount restriction*
38 1 Jessica Mack
This is parsed, but not enforced.  Here we should only allow teh client to mount a subdirectory (or something beneath it).  That means that any open-by-ino needs to ensure that the ino is part of that subtree.  I think this can happen int eh request path, somewhere in the neighborhood of rdlock_path_pin_ref() or rdlock_path_xlock_dentry(). 
39 1 Jessica Mack
* verify that any lookup-by-ino (targeti?) lives in the subtree
40 1 Jessica Mack
* possibly special case allow inodes where we have a remote dentry inside the subtree pointing to something outside of it?  at the very least we need to handle inodes that are in a straydir if their previous owner was in the correct tree.  This may be tricky to establish :(
41 1 Jessica Mack
 
42 1 Jessica Mack
*Extend file layout ceph_file_layout to specify a namespace id (uint64_t?)*
43 1 Jessica Mack
Right now this layout specifies a data pool number.  It could also specify a namespace id, or 0 for none.  The actual rados namespaces are described by strings, but we could make the cephfs ones be decimal string forms of the namespace numbers.
44 1 Jessica Mack
We have two unused fields in this struct we could reclaim:
45 1 Jessica Mack
46 1 Jessica Mack
p((. __le32 fl_cas_hash;  // never used
47 1 Jessica Mack
     __le32 fl_unused;     // used to be the preferred pg, removed years ago
48 1 Jessica Mack
49 1 Jessica Mack
Perhaps 2^32 namespaces is enough and we just use one of them.
50 1 Jessica Mack
This would require changes in
51 1 Jessica Mack
* mds: parse virtual xattrs for this field
52 1 Jessica Mack
* mds: use this namespace for all backtrace operations
53 1 Jessica Mack
* mds: do any file probe or cleanup in this namespace
54 1 Jessica Mack
* mds: use this namespace for backtraces
55 1 Jessica Mack
* cephfs-journal-tool: use proper namespace for any scavenge/repair operations 
56 1 Jessica Mack
* Client: use this namespace for io, both sync and ObjectCacher-initiated
57 1 Jessica Mack
* libceph.ko: generic namespace support
58 1 Jessica Mack
* ceph.ko: use correct namespace for any IO 
59 1 Jessica Mack
 
60 1 Jessica Mack
h3. Work items
61 1 Jessica Mack
62 1 Jessica Mack
h4. Coding tasks
63 1 Jessica Mack
64 1 Jessica Mack
# expand MDSAuthCap grammar to capture any/all of the above
65 1 Jessica Mack
# root squash
66 1 Jessica Mack
# path-based mount restrictions
67 1 Jessica Mack
# namespaces for ceph_file_layout