On Wed, May 27, 2015 at 5:37 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: > On Wed, 27 May 2015, Gregory Farnum wrote: >> 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. > > Oh, right. I was assuming the MDS is configured with some uid->gid > backend. But many won't have or want that, and > >> 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 think this makes perfect sense. :) > > So, the use-cases are now: > > 1) No authentication: 'allow any'. What we have now. > > 2) Subtree restriction: 'allow rw path /foo'. > > 3) Uid and group restriction: 'allow rw uid 123 gids 123,1000,1001'. > > 4) Uid restriction + some backend: 'allow rw uid 123'. MDS will do some > call-out to map each uid to a gid list. > > 5) Kerberos: 'allow rw kerberos blah blah'. Client presents user tickets > to MDS, and MDS will do the call-out to map that to a uid + gid list. > > 6) 2 + 3 > > 7) 2 + 4 > > 8) 2 + 5 > > And then later, maybe, > > 9) 2 + a different backend for each subtree. > ... > >> I feel like our meanings are sliding past each other again here. :( > > Hopefully not? :) > sage Hurray! -- 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
