On 22/05/2015 23:02, Gregory Farnum wrote:
On Fri, May 22, 2015 at 2:35 PM, Sage Weil <sweil@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
