On Fri, May 22, 2015 at 3:52 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: > On Fri, 22 May 2015, Gregory Farnum wrote: >> On Fri, May 22, 2015 at 3:18 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: >> >> What would it mean for a user who doesn't have no_root_squash to have >> >> access to uid 0? Why should we allow random users to access any UID >> >> *except* for root? Does a client who has no_root_squash and anon uid >> >> 123 get to access stuff as root, or else as 123? Can they access as >> >> 124? >> > >> > I can't tell what you mean... :( >> > >> > I'm guessing you're getting at root_squash being a weak tool, since it >> > mostly only prevents you from doing something that only root could do (a >> > compromised client can just claim to be any uid). A weak tool is still a >> > tool, though, and one that people can make use of. >> >> I guess maybe I am. But it's not just that: it's that I don't >> understand how it interacts with specifying UIDs. I would *expect* >> that we grant specific cephx keys access to specific UIDs, > > allow uid 1 rw > allow uid 2 rw > >> or to "any except root", > > allow rw options root_squash > >> or to "any". > > allow rw # implied no_root_squash > >> But the usage of root_squash implies that any client can try to act as >> any UID and we'll let them. > > Yes... any uid *except* uid 0. > >> So if a key says "no_root_squash, allow uid=123, allow gid=123", does >> that key allow the client to act as root? I think it *does*, but it >> *shouldn't*. > > Do you mean > > allow rw options # implied no_root_squash > allow uid 123 rw > allow gid 123 rw > > ? Because the 2nd and third are no-ops since the first will already let > 123 and any-other non-0 uid (or gid) do a write. > > Or, do you mean > > allow uid 123 gid 123 options no_root_squash > > In that case, I think no_root_squash is a meaningless option because we > have already said 'uid 123' only please. So here you've said that no_root_squash is meaningless because of a different set of granted permissions; that doesn't sound strictly additive to me. Or do you mean (as John implies below) that no_root_squash will not squash the user and then it will fail because it doesn't have adequate access permissions? On Tue, May 26, 2015 at 5:56 AM, John Spray <john.spray@xxxxxxxxxx> wrote: > This feels more like a syntax issue: as you say, these NFS-esque options > don't make sense as part of a list of additive capabilities, they're more > like a single structure with some fields. The naming is potentially > confusing too; we're really talking about a condition under which we squash > a UID (never, when requester was root, or always), and then how we do the > squashing (to which UID/GID). > > A syntax that doesn't allow the nonsensical combinations of options might be > something like: > squash: <none|all|root> > squash_to: <uid> <gid> > capabilities: [existing additive list style] [] []... > > (or even a list of those structures, so that admin could define e.g. > multiple path-limited capabilities, each with different squashing rules). > > But maybe it is a good idea to avoid introducing this to users as "it's like > NFS" to avoid confusion. Yes, something like this makes a lot more sense to me. Although I'd almost expect/want it to be done client-side rather than on the server: the server is responsible for making sure clients have permission to do what they're asking; the clients are responsible for forming their requests in a way that they have permission. Is that nonsensical? -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
