Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review

[Nico Williams <[e-mail]>]

I should add that one personal motivation for v3 was "disk-less"
clients: they should be able to have access to shares they "own" as if
they had been local filesystems, but without the ability to make
arbitrary assertions about process credentials -user, group IDs,
privileges, labels- they couldn't quite get local filesystem access
control semantics.

I ran into this problem when Least Privilege integrated into Solaris,
something like 10 years ago or so.  Roughly around the same time that
(maybe a year after) I noticed the cache poisoning problem.

Without RPCSEC_GSSv3, the best a disk-less client can do w.r.t. shares
it "owns" is:

 - use AUTH_SYS, with all its limitations (no cryptographic security),
   for conveying subject process identity (user ID/group ID)

or

 - use host credentials ("root") and chown/chgrp new objects, and
   evaluate ACLs locally

Both of those options were just... awful.  The ability to securely make
arbitrary assertions, using name@domain form for identity assertions,
was my solution.  This explains the criticality design: the client can
just always make these assertions and let the server grant these for the
shares owned by the client and not for others.

Nico
--