Troy Benjegerdes wrote: > On Tue, Jul 05, 2005 at 01:09:45AM -0400, Jeffrey Altman wrote: > >>Troy Benjegerdes wrote: >> >>>On Fri, Jul 01, 2005 at 02:28:13PM -0400, Ken Hornstein wrote:
>>>FYI, when using Kerberos V5 native tickets, 'user/admin' type principals
>>>don't resolve to 'user.admin' afs ID's, only 'user'.
>>>
>>>Using -524 gets the regular krb5 user.admin ticket, so it works.
>>
>>That means that 524 is a security hole.
>
>
> Hrrm? hasn't the 'user/admin' kerberos ticket to 'user.admin' AFS id
> always been standard?
>
> FYI, after reading the source a bit, the following fixes the native K5
> stuff..
>
> @@ -622,7 +623,7 @@
> strncpy(username, get_princ_str(context, v5cred->client, 0),
> len);
> username[len] = '\0';
>
> - if (second_comp(context, v5cred->client) > 1) {
> + if (second_comp(context, v5cred->client)) {
> strcat(username, ".");
> p = username + strlen(username);
> len = min(get_princ_len(context, v5cred->client, 1),
This doesn't fix the problem. This opens the security hole for aklog
with krb5 tickets as well. The problem is that there is no way to
distiguish between two krb5 principals;
[EMAIL PROTECTED]
user/[EMAIL PROTECTED]
Two identities in Kerberos should not be treated as the same identity in
AFS.
smime.p7s
Description: S/MIME Cryptographic Signature
