[2370] in Kerberos-V5-bugs
krb5-libs/129: krb5_sname_to_princ needs a realm argument
daemon@ATHENA.MIT.EDU (bjaspan@MIT.EDU)
Tue Oct 22 17:02:27 1996
Resent-From: gnats@rt-11.MIT.EDU (GNATS Management)
Resent-To: krb5-unassigned@RT-11.MIT.EDU
Resent-Reply-To: krb5-bugs@MIT.EDU, bjaspan@MIT.EDU
Date: Tue, 22 Oct 1996 17:01:00 -0400
From: bjaspan@MIT.EDU
Reply-To: bjaspan@MIT.EDU
To: krb5-bugs@MIT.EDU
>Number: 129
>Category: krb5-libs
>Synopsis: krb5_sname_to_princ needs a realm argument
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: krb5-unassigned
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Tue Oct e 17:02:00 EDT 1996
>Last-Modified:
>Originator: Barry Jaspan
>Organization:
mit
>Release: 1.0-development
>Environment:
System: SunOS DUN-DUN-NOODLES 5.4 Generic_101945-37 sun4m sparc
>Description:
krb5_sname_to_principal does not take a realm name as an argument.
This means that any program that wants to use sname_to_princ but wants
to allow users to override the krb5.conf default realm via the command
line has to munge the realm component of the result of sname_to_princ
directly. This is ugly, and currently rlogin/rsh/rcp, kprop/d, and
probably telnet/d do it this way. See [krb5-admin/39].
A better solution would be for krb5_sname_to_principal to take a realm
argument. This can be accomplished in two ways: 1, a new function
krb5_sname_to_princ_with_realm or 2, by adding a new argument to the
existing principal, using API versioning. This would be a nice test
case for the api versioning system.
>How-To-Repeat:
>Fix:
>Audit-Trail:
>Unformatted:
