> On May 29, 2018, at 3:56 PM, bfields@xxxxxxxxxxxx wrote:
>
> On Tue, May 22, 2018 at 03:36:12PM -0700, Chuck Lever wrote:
>>> On May 22, 2018, at 3:11 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote:
>>>> If an AUTH_UNIX client can tamper with a lease established
>>>> by an AUTH_GSS client, that's a pretty serious server bug.
>>>>
>>>> Which server implementation is this?
>>>
>>> This is linux 4.16-rc1.
>>
>> Would it be easy for you confirm if two AUTH_GSS clients are
>> appropriately protected from each other? It would be good to
>> file a bug on bugzilla.linux-nfs.org to document the full
>> extent of the badness.
>
> If you try a setclientid with a client name matching an
> already-established client with state, then nfsd4_setclientid() should
> be returning CLID_INUSE:
>
> if (conf && client_has_state(conf)) {
> ...
> status = nfserr_clid_inuse;
> ...
> if (!same_creds(&conf->cl_cred, &rqstp->rq_cred)) {
> ...
> goto out;
> }
> }
>
> So if you're seeing SETCLIENTID succeed then maybe same_creds() or
> client_has_state() is failing.
>
> Maybe client_has_state()?--that will fail (and allow the setclientid) if
> the v4.0 client doesn't currently have any opens or delegations.
>
> I think that's correct:
>
> https://tools.ietf.org/html/rfc7530#section-9.1.2
>
> when the server gets a SETCLIENTID for a client ID that
> currently has no state, or it has state but the lease has
> expired, rather than returning NFS4ERR_CLID_INUSE, the server
> MUST allow the SETCLIENTID and confirm the new client ID if
> followed by the appropriate SETCLIENTID_CONFIRM.
>
> That's left out of the later breakdown of cases in 16.33.5,
> unfortunately.
That prevents certain denial of service attacks. A client can't
lose state because of this. However, it can do a SETCLIENTID
then later be prevented from doing its first OPEN?
--
Chuck Lever
--
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
