On Thu, Aug 09, 2012 at 04:52:07PM -0400, Chuck Lever wrote: > > On Aug 9, 2012, at 4:46 PM, Chuck Lever wrote: > > > > > On Aug 9, 2012, at 4:38 PM, J. Bruce Fields wrote: > > > >> On Thu, Aug 09, 2012 at 03:37:43PM -0400, J. Bruce Fields wrote: > >>> On Thu, Aug 09, 2012 at 03:06:00PM -0400, Chuck Lever wrote: > >>>> > >>>> On Aug 9, 2012, at 2:35 PM, J. Bruce Fields wrote: > >>>> > >>>>> Sorry not to notice this before--the below causes a regression against > >>>>> the Linux server; something like: > >>>>> > >>>>> # mount -osec=krb5i pip1:/exports /mnt/ > >>>>> # echo "test" >/mnt/test > >>>>> # umount /mnt/ > >>>>> # mount -osec=krb5 pip1:/exports /mnt/ > >>>>> # echo "test" >/mnt/test > >>>>> bash: /mnt/test: Operation not permitted > >>>>> > >>>>> This fails after the below commit on the client, but not before, thanks > >>>>> to the server rejecting the second setclientid with CLID_INUSE due to a > >>>>> different security flavor. > >>>> > >>>> This was part of a series where the last few patches got dropped for other problems. Testing with this patch by itself was never done since it was part of a series of patches that implement a particular feature. > >>>> > >>>> One thought is to put the authentication flavor name back into nfs_client_id4.id string temporarily until we have worked through the issues with full UCS support. That would prevent the regression, but we'd still have clients who use multiple authentication flavors maintaining multiple leases. > >>> > >>> That should work. > >> > >> Whoops, no, au_name is just "RPCSEC_GSS" in both cases. > > > > Could you confirm that before that commit, the client had to send an additional SETCLIENTID with a new cl_id_uniquifier? Confirmed. > > We'll need to distinguish the pseudoflavor as well for GSS, > > apparently. > > The client should present the same principal on both SETCLIENTID > requests, shouldn't it? If the principal is the same, that's all that > RFC 3530bis requires. Maybe I don't understand how GSS principals > work. Which rfc3530bis language are you looking at? I remember it being a bit vague. Looking at the spec.... "a deliberate change of the principal owner of the id string (such as the case of a client that changes security flavors, and under the new flavor, there is no mapping to the previous owner) will in rare cases result in NFS4ERR_CLID_INUSE." Which makes it sound like the server can arbitrarily decide how to map principals sent with different flavors--which doesn't offer much guidance about what to do. The server could just compare principal strings (and ignore pseudoflavors) in the gss case. If the intention is to ensure that a clientid can't be "hijacked" by someone malicious, then you don't want to allow a krb5 setclientid to blow away a clientid established with krb5i. (If sending the setclientid with krb5i indicates the client wants protection against attacks which replace the body of the rpc, then a later krb5 setclientid should be rejected, since it could be the product of such an attack.) --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
