(taking to ceph-devel) On Mon, Feb 20, 2017 at 4:27 PM, Ramana Raja <rraja@xxxxxxxxxx> wrote: > Would it be possible or make sense to disallow clients having > path restricted caps (OpenStack clients) from modifying quota > (change share size) of the root of the exported subtree (manila share)? > > Currently, an OpenStack client can mount a share and modify > its size, by modifying the quota xattr value at the mount point, > without Manila service knowing about the size change. Right, I think this came up before at some point. I think I didn't think hard about it because it wouldn't be an issue so much with NFS clients, but we should at least decide what direction we want to go in. We had kind of the same issue with layouts, which is why the 'p' part of 'allow rwp' MDS auth caps was introduced. A few options spring to mind: A) Apply the 'p' flag rules quotas as well as layouts: generalise it into a "this is a client that isn't allowed to modify the special ceph.* attrs". Is this too Manila-specific? Not sure. B) Special case the client's mount root, and never let it modify the quotas on its own root. This is probably reasonable in practice as I would expect someone to only be mounting a subpath at the point they had configured their quotas elsewhere, but it seems like quite a quirky move. C) Introduce another flag to the mds auth caps that controls ability to set quota. Downside: additional complexity in the auth caps. D) Do nothing Anyone have other thoughts on this, and/or a preference from those options? I'm leaning towards A but just because I can't readily imagine use cases where you want to permit layout changes but ban quotas, doesn't mean they don't exist. John -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
