svcgssd

[Fredrik Tolf]

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. 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