On Tue, May 26, 2015 at 3:17 PM, Sage Weil <sweil@xxxxxxxxxx> wrote:
> On Tue, 26 May 2015, Gregory Farnum wrote:
>> > That makes sense to me. I suggest
>> >
>> > - the MDS decides it is allowed. If so, do the presented operation.
>> > Preserve the const-ness of teh current permission checks.
>> >
>> > - the client may do some squashing before-hand.
>> >
>> > - forget what I said before and make this un-NFS-like. :)
>>
>> :)
>>
>> >
>> > Perhaps the illustrative example is this: an op to create a file, as uid
>> > 0, in a 777 directory comes in, and the capability says root_squash. In
>> > this case, our const check says "if i were to squash to 65534, it would
>> > still be allowed" and so the mds goes ahead and creates a file *owned by
>> > root*.
>> >
>> > Does that make sense?
>>
>> Mmm, I'm having trouble making this one work out. If you can write a
>> file with UID 0 you have to be able to subsequently read it, and I
>> just don't see that happening if you aren't doing an operation as UID
>> 0?
>
> The operation would be done as uid 0.
>
> (Also, I'm completely ignoring read operations for the moment... :/ )
Okay, let's not ignore that. If a read comes in as anonymous for a
file owned by UID 0 and without world-readable caps (which that write
operation you described can do), it fails. Correct?
I see that as a bit of a problem. :/
>
>> But this is getting thornier as we consider future multi-tenant (not
>> just multi-user) and subtree work. I've been imaging the subtree
>> restriction as *not additive*, in that it would be a restriction to
>> users.
>
> I think we're still talking past each other about 'additive'. I'm
> suggesting caps are *always* additive. That is, any operation permitted
> by
>
> allow A
>
> will also permit the same operation if you have
>
> allow A ; allow B
>
> for *any* B. B cannot effect A, and only one of the allow's needs to say
> "yes".
>
> ...but what does that have to do with path restrictions? If you have an
> allow A like
>
> allow rw path /foo
>
> that will allow something in /foo regardless of what other allow B's are
> added to the list.
>
> Right?
Okay, so that's one path we could go down. I'm not sure if it's the
right one or not.
In particular, I'd like us to be able to guarantee that users never
escape out of their given subtree. It seems like they could if it's
just a positive grant. Or maybe if the cephx caps don't include
anything else then no operations elsewhere will be disallowed? I guess
that should work. But in any case, not what you wrote in the pad:
> If a path is specified in the cap, only ops within that subtree are allowed.
:/
>
>> It looks like you've got similar ideas from the pad, so I don't
>> understand how the anonymous user would generally be allowed to do
>> things against the tree except read it?
>>
>> When looking at your pad and you say "if a UID is specified..." do you
>> mean specified within an op, or in the cephx caps? The first one makes
>> sense to me; the second won't work (not additive, etc).
>
> In the caps, where it is optional. The uid on the op will be required
> (modulo whatever we have to do for compatibility).
Okay, quoting from the pad:
> If the uid is specified in the cap, we only allow the operation if it is tagged with the same uid
> (and all other constraints are satisfied).
Maybe this is the right way for us to go, but that's definitely not
additive: it *disallows* the operation if its UID doesn't match the
one in this cephx cap, regardless of what anything else says.
UIDs like this I think can and should be strictly additive. We
probably want to include ranges or some other sort of aggregation, but
I don't see much point to making them optional restrictions the way I
see for the path-based stuff?
Or (looking below) perhaps you mean the uid for a specific grant, not
for all grants within the set of cephx caps. That does make a bit more
sense, and makes upgrades easier. Hrmm.
>
>> Basically I'm still stuck on how any of this lets us lock a user into
>> a subtree while letting them do what they want within it. I'm not sure
>> how/if NFS solves that problem...
>
> That's easy:
>
> # lock client into a dir
> allow rw path /home/user
>
> Or, for a shared model:
>
> # allow access to a project dir, as project or user gid
> allow rw path /share/project uid 123 gids 123,1000
I think I'm forgetting how the parsing works. Is that all one specific
allow stanza that is evaluated as a unit? Ie, to match it an operation
must fall within /share/project and be sent by a user with either UID
123 or GID{123,1000}? You're right, that works.
>
> Ooh... are you thinking forward to when we might have to dynamically write
> a cap that implements changing kerberos auth information? For that, I'd
> suggest something like
>
> allow rw path /foo kerberos
>
> ...where that then does an additional check against any kerberos tickets
> info we've gotten from the client session?
>
> sage
--
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
