On Mon, Oct 10, 2022 at 4:03 AM Xiubo Li <xiubli@xxxxxxxxxx> wrote: > No, it don't have to. This could work simply as the snaprealm hierarchy > thing in kceph. > > Only the up top directory need to record the ACL and all the descendants > will point and use it if they don't have their own ACLs. Not knowing much about Ceph internals, I don't quite understand this idea. Until somebody implements that, I'll keep my patch in our Linux kernel fork. My patch is a very simple and robust fix for our problem (it's already in production use). It's okay for me if it doesn't get merged into mainline, but at least I wanted to share it. > For multiple clients case I think the cephfs capabilities [3] could > guarantee the consistency of this. I don't understand - capabilities are client-specific, not user-specific. My problem is a user-specific one. > While for the single client case if > before the user could update its ACL just after creating it someone else > has changed it or messed it up, then won't the existing ACLs have the > same issue ? You mean ACLs for "real" files/directories? Sure, some care needs to be taken, e.g. create directories with mode 700 and chmod after setting the ACL, and using O_TMPFILE for files and linking them to a directory only after updating the ACL. The difference to snapdir is that the snapdir doesn't actually exist anywhere; it is synthesized by the client only on the first acess, and may be discarded any time by the shrinker, and the next access creates a new one with default permissions. All those snapdir inodes are local to the client, and each client has its own private set of permissions for it. Even if you'd take care for updating the snapdir permissions after creating a directory, that would only be visible on that one client, and may be reverted at any arbitrary point in time, and there's nothing you can do about it. That's two unsolvable problems (no client synchronization of snapdir permissions, and no persistence). Max
