On 9/12/24 04:14, Patrick Donnelly wrote:
On Wed, Sep 11, 2024 at 3:21 PM Max Kellermann <max.kellermann@xxxxxxxxx> wrote:
On Wed, Sep 11, 2024 at 8:04 PM Patrick Donnelly <pdonnell@xxxxxxxxxx> wrote:
CephFS has many components that are cooperatively maintained by the
MDS **and** the clients; i.e. the clients are trusted to follow the
protocols and restrictions in the file system. For example,
capabilities grant a client read/write permissions on an inode but a
client could easily just open any file and write to it at will. There
is no barrier preventing that misbehavior.
To me, that sounds like you confirm my assumption on how Ceph works -
both file permissions and quotas. As a superuser (CAP_DAC_OVERRIDE), I
can write arbitrary files, and just as well CAP_SYS_RESOURCE should
allow me to exceed quotas - that's how both capabilities are
documented.
Having root on a client does not extend to arbitrary superuser
permissions on the distributed file system. Down that path lies chaos
and inconsistency.
Fine for me - I'll keep my patch in our kernel fork (because we need
the feature), together with the other Ceph patches that were rejected.
If you want to upstream this, the appropriate change would go in
ceph.git as a new cephx capability (not cephfs capability) for the
"mds" auth cap that would allow a client with root (or
CAP_SYS_RESOURCE) to bypass quotas. I would support merging such a
patch (and the corresponding userspace / kernel client changes).
Yeah, Patrick is correct. This really will by pass the protocols and
restrictions in cephfs and introduces inconsistency. By adding a new
cephx caps we can broadcast this to all the users or clients.
Thanks
