svcgssd

[J. Bruce Fields]

On Mon, Jul 03, 2006 at 07:10:05PM +0200, Fredrik Tolf wrote:
> There's one thing that I've just assumed so far, but from what you
> write, I'm not so sure if it's correct anymore. What I've assumed is
> that the kernel knows the UID or NFSv4 username -- is that correct?

I'm not sure what you're asking.

> If it is not, then what is the purpose if idmapd? Isn't its purpose to map
> UIDs to usernames (and vice versa) so that a username can be sent over NFS?
> Or is the kernel supposed to just be able to know the login user from the GSS
> name?  In that case, it almost sounds like a bug in the protocol...

There are three different types of names:

	local names, equivalent to local uid's
	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.
	gss names, such as kerberos principal names

When using NFSv4 over rpcsec_gss, NFSv4 names are the *only* names that go over
the wire.

The job of idmapd is to translate between local and NFSv4 names, so the kernel
asks idmapd to help with setattr and getattr operations.

The job of svcgssd is to establish new contexts, and to translate those
contexts to uid's and gid's.  So after a new cryptographic context is set up,
svcgssd hands the server's kernel a message saying "here's all the stuff
(session keys, etc.) you need to use this context; and here's the uid and the
list of gid's that you should associate with this context".

--b.