On Tue, Oct 11, 2022 at 11:27 AM Luís Henriques <lhenriques@xxxxxxx> wrote: > I'm not really sure where (or how) exactly this feature should be > implemented, but I agree with Xiubo that this approach doesn't look > correct. This would be yet another hack that can be easily circumvented > on the client side. If this feature is really required, the restriction > should be imposed on the MDS side. I think this is the wrong way to look at this problem. This is like saying the client can circumvent file permissions by pretending to be the owning uid. This isn't about restricting a client to see/create/delete snapshots; we need to agree that this is about clients which already have the permission to do this. This is about restricting which users (uids) on a client will be allowed to do that. The server cannot possibly implement this restriction; all it can do is give kind hints to the client, like it currently does with regular file permissions. But it's up to the client's kernel (the cephfs driver and the VFS) to enforce those per-uid permissions. This approach is already implemented in cephfs currently. All my patch does is allow overriding the mode mask, instead of inheriting the parent's mode mask. So if you say "this approach doesn't look correct", then you're actually saying that cephfs which is shipped in Linux mainline kernels isn't correct. That is certainly a reasonable opinion, but it's not about my patch. > (However, IMHO the feature looks odd from the beginning: a user that owns > a directory and has 'rw' access to it but can't run a simple 'mkdir' is > probably breaking standards compliance even more.) There is "prior art" for that: read-only mounts and immutable files. On both, you can have the "w" permission bit but cannot actually write. Max
