On Wed, May 27, 2015 at 4:59 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: > On Wed, 27 May 2015, Gregory Farnum wrote: >> On Wed, May 27, 2015 at 4:07 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: >> > On Wed, 27 May 2015, Gregory Farnum wrote: >> >> On Wed, May 27, 2015 at 3:21 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: >> >> > On Wed, 27 May 2015, Gregory Farnum wrote: >> >> >> > I was just talking to Simo about the longer-term kerberos auth goals to >> >> >> > make sure we don't do something stupid here that we regret later. His >> >> >> > feedback boils down to: >> >> >> > >> >> >> > 1) Don't bother with root squash since it doesn't buy you much, and >> >> >> > 2) Never let the client construct the credential--do it on the server. >> >> >> > >> >> >> > I'm okay with skipping squash_root (although it's simple enough it might >> >> >> > be worthwhile anyway) >> >> >> >> >> >> Oh, I like skipping it, given the syntax and usability problems we went over. ;) >> >> >> >> >> >> > but #2 is a bit different than what I was thinking. >> >> >> > Specifically, this is about tagging requests with the uid + gid list. If >> >> >> > you let the client provide the group membership you lose most of the >> >> >> > security--this is what NFS did and it sucked. (There were other problems >> >> >> > too, like a limit of 16 gids, and/or problems when a windows admin in 4000 >> >> >> > groups comes along.) >> >> >> >> >> >> I'm not sure I understand this bit. I thought we were planning to have >> >> >> gids in the cephx caps, and then have the client construct the list it >> >> >> thinks is appropriate for each given request? >> >> >> Obviously that trusts the client *some*, but it sandboxes them in and >> >> >> I'm not sure the trust is a useful extension as long as we make sure >> >> >> the UID and GID sets go together from the cephx caps. >> >> > >> >> > We went around in circles about this for a while, but in the end I think >> >> > we agreed there is minimal value from having the client construct anything >> >> > (the gid list in this case), and it avoids taking any step down what is >> >> > ultimately a dead-end road. For example, caps like >> >> > >> >> > allow rw gid 2000 >> >> > >> >> > are useless since the client can set gid=2000 but then make the request >> >> > uid anything it wants (namely, the file owner). Cutting the client out of >> >> > the picture also avoids the many-gid issue. >> >> >> >> I don't think I understand the threat model we're worried about here. >> >> (Granted a cap that sets gid but not uid sounds like a bad idea to >> >> me.) But if the cephx caps include the GID then a client can only use >> >> weaker ones than they're permitted, which could frequently be correct. >> >> For instance if each tenant in a multitenant system has a single cephx >> >> key, but they have both admin and non-admin users within their local >> >> context? >> > >> > Not sure I understand the question. The threat model is... a client that >> > can send arbitrary requests and wants to modify files? >> > >> > - Any cap that specifies gid only is useless, since you can choose a uid >> > to match the file. >> > >> > - Any cap that specifies uid only exposes any group-writeable files/dirs. >> > >> > - Any cap that specifies uid and gid(s) is fine. >> > >> > ...but if we have a server-side mapping of uid -> gid(s), then any of >> > those is fine (we can specify uid only, gid only, or both). >> >> Okay, so it's just malformed cephx caps then. We could just make it >> refuse to accept gid specs if there's not a uid one as well. > > Well... it's meaningless if the client gets to choose the gid set. If we > don't do that, then it depends on what the server-side does. If kerberos > is used (i.e., the user doesn't get to choose an arbitrary uid) then it's > okay. But yeah, I guess we should disallow it for now until that becomes > available, since in the meantime even with server-side uid->gid mapping > they can pick any uid. > >> Not that I'm necessarily opposed to doing it server-side, but I'm not >> sure where we'd store it in the minimal configuration (without >> kerberos or some other server to do lookups in) and not including them >> in the cephx caps just feels odd. > > Yeah. In fact, if we do have a server-side uid->gid map, and a cap like > > allow rw uid 100 gid 100 > > does the gid part actually accomplish anything? I'm thinking it doesn't, > and we can just forget gid in the caps entirely for the time being? I > mean, maybe the user is in groups 100, 200, and 300, but we only want to > them act as though they're in 100 for this mount.. but who would even want > to do that, and do we care at this point? I don't understand. In the base case where there is no other user authentication/authorization system in place, we need to either support group allows in the cephx caps, or we disallow the use of groups, or each individual user/mount can claim to be a member of whatever group they want. So that makes me think we need to support group allows in the cephx caps, of form something like allow rw uid 100 gid 100,200,300 That would let the client act as user 100 and as a member of groups 100, 200, and 300 (*only* with uid 100!) if they so desire. That enables lots of important use cases with sharing, right? And it's not the client choosing the allowed set, it's the Ceph administrator. Is there something about this that we don't want to enable that I'm just missing, or are you ignoring the non-Kerberos case, or is there some conflict between this and the Kerberos case, or....? I feel like our meanings are sliding past each other again here. :( -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
