Subject: Gss Context and sequence window

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Wed, 30 Oct 2002 11:28:08 -0500

Is the GSS context negotiated for a user on one mount point/communication 
channel supposed to be shared with all other mount points/communication 
channels for that user on that server? The question at issue is whether or not 
it is possible to have multiple contexts for a given user against a given 
server in order to avoid having a global serialization w.r.t. the sequence 
number.

Cheers,
  Andy, Bruce, Trond

---

From: Mike Eisler <[email-masked]>
Date: Wed, 30 Oct 2002 12:08:00 -0800

> server in order to avoid having a global serialization w.r.t. the sequence

The client can do whatever makes sense for it. The server, especially
an NFSv4 server needs to be able to accept the context through all
exported directories. It also must accept multiple contexts from
the same user. This is critical for performance; most client do
read ahead and write behind and in the case of the Solaris client,
8-9 contexts per user/mount pair get created.

(As an implementation aside, if you are using the MIT krb5 code,
you'll note that its context creation path is not re-entrant ...
simulataneus context creations are likely to crash. So you'll need to
serialize context creation or make the code re-entrant).

It is indeed possible and expect for a given user to have lots of
contexts against a given server.

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Wed, 30 Oct 2002 15:27:34 -0500

> contexts against a given server.

wow. so, my nfsv4 login client that will have 250 simultaneous users will be 
spending a bunch of time creating contexts to a given server/mountpoint even 
though the only difference is the sequence numbering??

-->Andy

---

From: Mike Eisler <[email-masked]>
Date: Wed, 30 Oct 2002 12:29:06 -0800

One other thing ... the RPCSEC_GSS context, once created, is typically
"locked down" by the server so that the client can't substitute
a weaker service (authentication, integrity) or quality of
protection (QOP) for an exported hierarchy that requires stronger
QOPs or services. This was done in the Solaris server to minimize
the costs of checking this stuff on each NFS access. So the
client should not assume that it can vary the service and qop for
a created rpcsec_gss context.

	-mre

---

From: Mike Eisler <[email-masked]>
Date: Wed, 30 Oct 2002 12:38:04 -0800

> though the only difference is the sequence numbering??

Like I say, whatever makes sense for the client.

In general, GSS-API mechanisms are not MT safe (which was the basis
for my performance issue above). If you can multiplex all
of a user's traffic over one context, great.

(In v4, I think much more memory for state gets used for opens and
locks than contexts).

	-mre