On Tue, May 29, 2018 at 04:03:46PM -0400, Chuck Lever wrote:
>
>
> > 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?
Yeah, I think so.
Looking back at changelogs, the only motivation was to avoid annoyances
in testing, where the same client might rapidly mount several different
security flavors. The client may have been wrong not to change its
identifier in that case, I don't know.
All a bit academic for 4.1, where the client pretty much always has a
session.
--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
