On Wednesday, July 06, 2005 05:11:56 PM -0400 Ken Hornstein
<[EMAIL PROTECTED]> wrote:
For AFS, the problem is made somewhat worse by the fact that we
construct usernames by concatenating the V4 name and instance with a
dot, but only when the instance has non-zero length. This behavior
depends on the premise that a V4 principal name will never contain a
".". While krb524d is broken and does not enforce this restriction,
the V5 ticket handling code in rxkad does. The reasoning is the same
as above -- mapping multiple distinct V5 principals to the same AFS
username could result in all sort of nasty security problems.
This is going to be my last message on this topic, honest.
That sort of makes it hard to come to any agreement.
- Clearly neither of the two open-source Kerberos implementations consider
this a security problem, as they do not perform this checking. If it
was a "nasty security problem", we'd see CERT warnings issued and
patches to correct the problem.
Neither of the two open-source Kerberos implementations contains a function
which maps a Kerberos V5 principal to a string containing an AFS username.
They contain functions which map V5 principals to V4 principals represented
as a set of three strings, in which it is easy to distinguish between a
principal with name "jhutz.admin" and instance "" and a principal with name
"jhutz" and instance "admin". AFS usernames don't have that property, and
so there are additional possible collisions which AFS needs to detect.
Probably rxkad should reject _V4_ principals with a "." in the name, since
there are things (like krb524d) which do not conform to what AFS assumes is
an invariant. But I'm not insisting that we fix this problem, only that we
don't create new ones.
- This could only conceivably be an issue if you allow users to create
arbitrary principal names. I know that CMU allows users to create
arbitrary instances for some strange reason, but even you have to
admit that this is a rather uncommon practice.
Huh? Where did you get that idea?
For sites that don't
allow users to create arbitrary principals, the only thing this check
accomplishes is that it breaks things for V5 sites that have created
principals with "." in their names (it doesn't even do a mapping to
something else; it just silently rejects them!)
It prevents the case where a new user at mondo-big-site says "I want my
userid to be foo.root", and accounts, not knowing any better, creates it.
It also prevents the case where a site assumed that "foo.root" and
"foo/root" were different principals gets screwed becaose AFS decides they
really aren't.
I'm not asking for those sites to be broken. I'm happy to give them a
feature that makes things suck less for them. However, I want
- no new complex changes before 1.4
- no hidden time bombs as a result of upgrading to 1.4
I think I'd be OK with making a change as part of a larger naming overhaul,
which I expect/hope will happen anyway. I expect that such a change will
require that administrators pay attention before they get any new behavior,
since it will likely moving mapping into the ptserver and making a change
to the prdb format.
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
