[OpenAFS-devel] Re: MEMORY credential cache interop between Heimdal and MIT?

[Marcus Watts]

Ok.  I think there are some fundamental misassumptions here, which
I may as well try to tackle.

Unix UIDS != afs pags.
Unix UIDS are sort of like AFS viceids.
Unix loginid is sort of like kerberos principal name.
Unix protection mask is sort of like AFS acls.
Unix process credentials are vaguely like AFS pags.

AFS pags are a credentials container.  They have
some relation to "setuid" -- but note that setuid manipulates
local machine credentials, badly.  AFS pags are a container
to store network credentials, with better default properties.

In Unix, we can do:
	login user1
	echo do stuff as user1
	su user2
	echo do stuff as user2
	...
note: we can't run one editor session and access files
both as user1 and as user2.  You know this limitation,
so it doesn't bother you.
But, even here, we can distinguish rule #1: login session != container.

In AFS, we can do:
	klog user1
	echo do stuff as user1
	pagsh
	klog user2
	ed some-file
	!echo do stuff as user2
	^Z
	klog user3 -cell another-cell
	fg
	r file-from-another-cell
	w file-as-user2
	^Z
	klog user4
	fg
	w file-as-user4
	q
	echo do more stuff as user3
	unlog
	exit
	echo now back to user1
here: because a pag != a credential, we can:
	add credentials to an already-existing pag
	we can discard existing credentials and acquire new ones,
	all within one authentication context, all inside
	one session.
Note the use of one container to hold more than one credential -
the credential in a remote cell.  That's convenient.  In a network
environment, this separation of credential and session is more than a
convenience, it's a requirement.  Kerberos tickets have a finite lifetime.
Unix processes have an indefinite lifetime.  We *have* to manage the idea
of having credentials expire -- and replace those credentials with at
least an unauthenticated credential, without making the process go away.
Making it possible to renew credentials then means we lose less badly
when the original credentials expire.  So, credentials are not containers.

Here's another example:

Unix,
window1					window2
	ftp nobody@remotesystem
	!echo now nobody			ftp nobody@remotesystem
	put file-to-remote-system		!echo now nobody
						get file-to-remote-system
now if "nobody" were a regular user, the ability to get/put files this way
is useful.  But!  User "nobody" comes from NFS and is supposed to mean
"no local rights".  The fact that in the above example, user "nobody"
has a distinct Unix uid and can create files, means he can share files
local to just himself.  This is odd and unintentional, but this is
probably mostly harmless.  Really, this particular example is just plain
silly.  But suppose instead of ftp we're using finger.  Suppose "put"
is actually a security hole in the system.  Now things are starting
to look a bit sinister.  If our 2nd session is not to ftp or finger,
but some other more specialized process that starts off as "nobody",
but is setuid to something else -- and if we've gone whole-hog on Unix
"everything is a file", now things are starting to look downright bad.
Now our first daemon can muck with the resources of the 2nd
daemon, even though that sharing is unintentional and unwanted.
>From a security standpoint, it would be nice if each instance of "nobody"
were unique and inviolate.  So sorry, Unix doesn't do that.
Many modern Unix systems run each system daemon under loginids like "_this"
and "_that" (unique to each) so that holes in one daemon won't affect another.
Well, at least you get particial protection.  But really, this is why you
should not confuse identifiers with containers.

Ok yes.  NFSv2.  You know it, you hate it.  It likes to send network
credentials around of the form "uid".  Oops!  Identifier != credential.

So.
	login session != container
	identifier != container
	credential != container
	identifier != credential
see a pattern here?

In a small scale monolithic system, you can afford some confusion here.
In a large scale networked environment, each means something different,
and deserves to be its own separate thing.

Having said all that, pags are certainly not the ultimate solution.
I think before we can discuss that, we need to recognize that
unix uids are not a better solution.

				-Marcus Watts