From bjaspan@MIT.EDU Tue Oct 22 17:01:03 1996
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id RAA14088 for <bugs@RT-11.MIT.EDU>; Tue, 22 Oct 1996 17:01:02 -0400
Received: from DUN-DUN-NOODLES.MIT.EDU by MIT.EDU with SMTP
id AA18461; Tue, 22 Oct 96 17:01:01 EDT
Received: by DUN-DUN-NOODLES.MIT.EDU (5.x/4.7) id AA29097; Tue, 22 Oct 1996 17:01:00 -0400
Message-Id: <9610222101.AA29097@DUN-DUN-NOODLES.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
Subject: krb5_sname_to_princ needs a realm argument
X-Send-Pr-Version: 3.99
System: SunOS DUN-DUN-NOODLES 5.4 Generic_101945-37 sun4m sparc
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.
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Unassigned Problem Report <krb5-unassigned@RT-11.MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/129: krb5_sname_to_princ needs a realm argument
Date: Mon, 4 Nov 1996 14:57:58 -0500
`Theodore Y. Ts'o' made changes to this PR.
*** /tmp/gnatsa002kB Mon Nov 4 14:57:29 1996
--- /tmp/gnatsb002kB Mon Nov 4 14:57:43 1996
***************
*** 16,22 ****
Maybe, but not for the 1.0 release.
From: Sam Hartman <hartmans@MIT.EDU>
To: Unassigned Problem Report <krb5-unassigned@rt-11.mit.edu>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/129: krb5_sname_to_princ needs a realm argument
Date: Wed, 10 Apr 2002 15:57:03 -0400 (EDT)
`Sam Hartman' made changes to this PR.
--- /tmp/gnats229-Wg Wed Apr 10 15:56:48 2002
+++ /tmp/gnats229Yrs Wed Apr 10 15:56:58 2002
@@ -19,7 +19,7 @@
+>Class: change-request
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id RAA14088 for <bugs@RT-11.MIT.EDU>; Tue, 22 Oct 1996 17:01:02 -0400
Received: from DUN-DUN-NOODLES.MIT.EDU by MIT.EDU with SMTP
id AA18461; Tue, 22 Oct 96 17:01:01 EDT
Received: by DUN-DUN-NOODLES.MIT.EDU (5.x/4.7) id AA29097; Tue, 22 Oct 1996 17:01:00 -0400
Message-Id: <9610222101.AA29097@DUN-DUN-NOODLES.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
Subject: krb5_sname_to_princ needs a realm argument
X-Send-Pr-Version: 3.99
Show quoted text
>Number: 129
>Category: krb5-libs
>Synopsis: krb5_sname_to_princ needs a realm argument
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: krb5-unassigned
>State: open
>Class: change-request
>Submitter-Id: unknown
>Arrival-Date: Tue Oct e 17:02:00 EDT 1996
>Last-Modified: Wed Apr 10 15:58:00 EDT 2002
>Originator: Barry Jaspan
>Organization:
mit>Category: krb5-libs
>Synopsis: krb5_sname_to_princ needs a realm argument
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: krb5-unassigned
>State: open
>Class: change-request
>Submitter-Id: unknown
>Arrival-Date: Tue Oct e 17:02:00 EDT 1996
>Last-Modified: Wed Apr 10 15:58:00 EDT 2002
>Originator: Barry Jaspan
>Organization:
Show quoted text
>Release: 1.0-development
>Environment:
>Environment:
System: SunOS DUN-DUN-NOODLES 5.4 Generic_101945-37 sun4m sparc
Show quoted text
>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.
Show quoted text
>How-To-Repeat:
Show quoted text
>Fix:
Show quoted text
>Audit-Trail:
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Unassigned Problem Report <krb5-unassigned@RT-11.MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/129: krb5_sname_to_princ needs a realm argument
Date: Mon, 4 Nov 1996 14:57:58 -0500
`Theodore Y. Ts'o' made changes to this PR.
*** /tmp/gnatsa002kB Mon Nov 4 14:57:29 1996
--- /tmp/gnatsb002kB Mon Nov 4 14:57:43 1996
***************
*** 16,22 ****
Show quoted text
>Synopsis: krb5_sname_to_princ needs a realm argument
>Confidential: no
>Severity: serious
! >Priority: medium>Confidential: no
>Severity: serious
Show quoted text
>Responsible: krb5-unassigned
>State: open
>Class: sw-bug
--- 16,22 ---->State: open
>Class: sw-bug
Show quoted text
>Synopsis: krb5_sname_to_princ needs a realm argument
>Confidential: no
>Severity: serious
! >Priority: low>Confidential: no
>Severity: serious
Show quoted text
>Responsible: krb5-unassigned
>State: open
>Class: sw-bug
>State: open
>Class: sw-bug
Maybe, but not for the 1.0 release.
From: Sam Hartman <hartmans@MIT.EDU>
To: Unassigned Problem Report <krb5-unassigned@rt-11.mit.edu>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/129: krb5_sname_to_princ needs a realm argument
Date: Wed, 10 Apr 2002 15:57:03 -0400 (EDT)
`Sam Hartman' made changes to this PR.
--- /tmp/gnats229-Wg Wed Apr 10 15:56:48 2002
+++ /tmp/gnats229Yrs Wed Apr 10 15:56:58 2002
@@ -19,7 +19,7 @@
Show quoted text
>Priority: low
>Responsible: krb5-unassigned
>State: open
->Class: sw-bug>Responsible: krb5-unassigned
>State: open
+>Class: change-request
Show quoted text
>Submitter-Id: unknown
>Arrival-Date: Tue Oct e 17:02:00 EDT 1996
>Last-Modified: Mon Nov e 14:59:00 EST 1996
>Unformatted:
>Arrival-Date: Tue Oct e 17:02:00 EDT 1996
>Last-Modified: Mon Nov e 14:59:00 EST 1996
>Unformatted: