On Mon, Feb 20, 2017 at 8:43 AM, John Spray <jspray@xxxxxxxxxx> wrote: > (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. I like A but it does restrict the ability of tenants to have a "tenant admin" restricting the size of certain of their clients. Not sure if we care about that use case or not. -Greg -- 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
