svcgssd

[William A.(Andy) Adamson]

hi fredrik

> On Mon, 2006-07-03 at 13:23 -0400, J. Bruce Fields wrote:
> > There are three different types of names:
> > [...]
> > 	NFSv4 names, which have the form user at domain, and are used only
> > 		in setattr and getattr operations that get or set file
> > 		owners or ACLS.
> > [...]
> > > When using NFSv4 over rpcsec_gss, NFSv4 names are the *only* names that go
> > > over the wire.
> > 
> > So, maybe this answers your question: when the server gets an rpc, that rpc
> > comes with a credential in the rpc header that includes a 32-bit "context id"
> > with a cryptographic signature. That context id is all the server gets.  It
> > maps the context id back to the gss name it found when the context was
> > established, and uses that to decide who the user is--there's no name or uid on
> > the wire.
> 
> I see. There was the source of my confusion. I was under the impression that an NFSv4
> name was passed along as well when the context was created. 

not an NFSv4 name, an RPCSEC_GSS security context name.

an NFSv4 domain == a unique UID/GID mapping space. the NFSv4 domain can 
contain multiple DNS/NIS services, and/or multiple kerberos/PKI security 
services.
so, the NFSv4 administrator picks one DNS/NIS domain as the domain portion of 
the
NFSv4 name 

user at v4domain

this name is what is used in the NFSv4 protocol for ACLs (and 
OWNER/OWNER_GROUP). there is a one to one mapping between the NFSv4 
user at v4domain and a UID.

there are also names in the RPCSEC_GSS protocol.
the GSS_init_sec_context for both kerberos and mutual auth SPKM-3 passes the 
users security context name in the GSS_init_sec_context token. for krb5 this 
is the users kerberos principal at REALM, for mutual auth SPKM-3, this is the 
users Distinguished Name from the X.509 certificate.

multiple GSS names are mapped to the same UID as the single user at v4domain.

for example, the university of michigan has a campus wide unique name->UID 
service.
so, i can run a campus wide NFSv4 domain, choose the DNS umich.edu as the v4 
domain name, and my NFSv4 ACL name would then be:

andros at umich.edu  which gets mapped to a UID, 23975

i have identity in 3 of the many university kerberos realms:

andros at UMICH.EDU, andros at CITI.UMICH.EDU, and andros at ATLAS.UMICH.EDU plus, i 
have a PKI identity

/C=US/ST=Michigan/L=Ann Arbor/O=University of Michigan/OU=CITI Production 
KCA/CN=andros/UID=andros/emailAddress=andros at CITI.UMICH.EDU

all 4 of these security names get mapped to my UID, 23975.

-->Andy

>As I wrote in another mail,
> the lack thereof is, at least to me, indicative of a bug in the protocol... every other
> Kerberos-authenticated protocol that I know of (Krb5 GSSAPI over SASL, krexec, ktelnet,
> ssh with gssapi-with-mic, etc.) passes a local (or semi-local, such as an NFSv4 name)
> name before or along with the creation of a Kerberos context. Kerberos itself
> essentially only uses krb5_aname_to_localname when authorizing a user who doesn't have
> a ~/.k5login file.
> 
> Either way, if the protocol doesn't include a local name, then I guess there isn't much
> that can be done about it. Using krb5_aname_to_localname seems to be, at least, the next
> best option, and can still be used with krb5_kuserok() (which checks .k5login).
> 
> I'll write a patch for that, but it will be for nfs-utils-1.0.7 (since 1.0.8 *still*
> doesn't compile under Gentoo(!)). Is there any chance you'll be able to use that in
> 1.0.8?
> 
> Fredrik Tolf
> 
> 
> _______________________________________________
> NFSv4 mailing list
> NFSv4 at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4