Re: MDS auth caps for cephfs

[John Spray <john.spray@redhat.com>]

On 22/05/2015 23:02, Gregory Farnum wrote:
> On Fri, May 22, 2015 at 2:35 PM, Sage Weil <sweil@redhat.com> wrote:
>> On Fri, 22 May 2015, John Spray wrote:
>> Yes, I think we should.  Part of me wants to say that people who want NFS-like
>> behaviour should be using NFS gateways.  However, these are all probably
>> straightforward enough to implement that it's worth maintaining them in cephfs
>> too.
> Unfortunately not really — the NFS semantics are very different from
> the way our CephX security caps work. We grant accesses with each
> permission, rather than restricting them. We can accomplish similar
> things, but they'll need to be in opposite directions:
> allow anon_access
> allow uid 123, allow gid 123[,456,789,...]
> allow root
> where each additional grant gives the session more access. (And I'm
> not sure if these are best set up as specific things on their own or
> just squashed in so that UID -1 is "anon", etc) These let you set up
> access permissions like those of NFS, but it's a quite different model
> than the various mounting and config file options NFS gives you. I
> want to make sure we're clear about not trying to match those
> precisely because otherwise our security capabilities are not going to
> make any kind of sense. :(
> 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 mean, I think it would have to mean they get access to everything as
> anybody, and I'm not sure which requests would be considered
> "anonymous" for the uid 123 bit to kick in. But I don't think that's
> what the administrator would *mean* for them to have.
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.

>
> As I think about this more I guess the point is that for multi tenancy
> we want each client to be able to do anything inside of their own
> particular directory namespace, since UIDs and GIDs may not be
> synchronized across tenants? I'm not sure how to address that, but
> either way I think it will require a wider/different set of primitives
> than we've described here. :/


The path limiting is the most important thing (protect clients accessing 
one subtree from clients accessing another subtree) but UID mangling is 
important too (protect multiple clients mounting same path from one 
another's local user DBs).  It's two different motivations.

I'm imagining that "access to path /foo/bar, all_squash to user 123" 
would be a very typical use case for multitenancy, for environments 
where each tenant is a single-UID application, but we don't really care 
what the local UIDs are.

>
>>> We probably need to mirror these in our mount options too, so that e.g.
>>> someone with an admin key can still enable root_squash at will, rather than
>>> having to craft an authentication token with the desired behaviour.
> Mmmm, given that clients normally can't see their capabilities at all
> that's a bit tricky. We could maybe accomplish it by tying in with the
> extra session exchange (that Sage referred to below); that will be
> necessary for adding clients to an existing host session dynamically
> and we could also let a user voluntarily drop certain permissions with
> it...although dropping permissions requires a client to know that they
> have them. Hrm.

The mount options could just be overrides that the client sends in the 
session open: it would be up to the MDS to perform the requested 
dropping of capabilities.  But now that I think about this more, the 
idea of defining a second syntax for clients to use to request 
subtractions from their capabilities becomes unappealing.  Maybe we 
should just say that what's in your MDSAuthCaps is what you get, and 
make sure that the associated tooling is simple enough for users to 
readily create these on a per-mount basis if they want different options.

John
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html