Minimal capabilities for CephFS clients

Why this matters in production

A CephFS client without path restriction sees the entire filesystem. On a shared filesystem that is every tenant’s data, and the restriction that prevents it lives in the cephx capability rather than in POSIX permissions — so getting it right is a storage-side decision, not an application one.

The three capabilities

ceph fs authorize cephfs client.app / rw

That helper generates the full set. Expanded, it is:

caps: [mds] allow rw fsname=cephfs
caps: [mon] allow r fsname=cephfs
caps: [osd] allow rw tag cephfs data=cephfs

The tag cephfs data=<fsname> form is important: it grants access to the filesystem’s data pools by tag rather than by name, so adding a data pool later does not require a capability change.

Path restriction

This is the mechanism that makes multi-tenant CephFS work:

ceph fs authorize cephfs client.tenant-a /tenants/a rw
ceph fs authorize cephfs client.tenant-b /tenants/b rw

Each client can only traverse and modify within its subtree. The MDS enforces this on every metadata operation — a client cannot escape its path by constructing its own requests, because the check is server-side.

ceph auth get client.tenant-a
# caps: [mds] allow rw fsname=cephfs path=/tenants/a

Read-only and multiple paths

# read-only access to a shared area plus read-write to its own
ceph fs authorize cephfs client.tenant-a /shared r /tenants/a rw

root_squash

ceph fs authorize cephfs client.untrusted /tenants/c rw root_squash

root_squash maps UID 0 on the client to an unprivileged identity, exactly as NFS does. Without it, root on the client host is root on the filesystem subtree, which for a client host you do not fully control is a significant grant.

Verifying enforcement

# mount as the restricted client, then attempt to escape
# MON is a monitor address from `ceph mon dump`; substitute your own:
MON=192.0.2.11:6789

mount -t ceph "$MON:/" /mnt/test -o name=tenant-a,secret=...
# should fail or show only the permitted subtree

ls /mnt/test/tenants/b        # must be denied

Test the denial. A path restriction that has not been tested from the client side is an assumption.

Quiz

Production discipline

Use ceph fs authorize rather than hand-writing CephFS capabilities — the tag-based OSD grant and the correct MDS clause are easy to get subtly wrong. Verify path restrictions by attempting to escape them from a real client, and apply root_squash by default on any host outside your administrative control.

Cross-course references

• Kubernetes: subPath volume mounts are a convenience, not a boundary, exactly as here
• Linux: NFS export path restrictions and root_squash are the direct analogues