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). -- Patrick Donnelly, Ph.D. He / Him / His Red Hat Partner Engineer IBM, Inc. GPG: 19F28A586F808C2402351B93C3301A3E258DD79D
