From HNELLORE@us.oracle.com Mon Mar 9 22:21:38 1998
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 WAA00553 for <bugs@RT-11.MIT.EDU>; Mon, 9 Mar 1998 22:21:33 -0500
Received: from inet16.us.oracle.com by MIT.EDU with SMTP
id AA24375; Mon, 9 Mar 98 22:21:31 EST
Received: from mailsun2.us.oracle.com (mailsun2.us.oracle.com [144.25.88.74])
by inet16.us.oracle.com (8.8.5/8.8.5) with SMTP id TAA00601
for <krb5-bugs@mit.edu>; Mon, 9 Mar 1998 19:21:30 -0800 (PST)
Received: by mailsun2.us.oracle.com (SMI-8.6/37.8)
id TAA28905; Mon, 9 Mar 1998 19:31:07 -0800
Message-Id: <199803100331.TAA28905@mailsun2.us.oracle.com>
Date: 09 Mar 98 19:00:27 -0800
From: "HNELLORE.US.ORACLE.COM" <HNELLORE@us.oracle.com>
To: krb5-bugs@MIT.EDU
Cc: HNELLORE@us.oracle.com
Subject: prepending a '\'
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: krb5-bugs@MIT.EDU, "HNELLORE.US.ORACLE.COM" <HNELLORE@us.oracle.com>
Cc: gnats-admin@RT-11.MIT.EDU, krb5-prs@RT-11.MIT.EDU
Subject: Re: pending/556: prepending a '\'
Date: Tue, 10 Mar 1998 02:27:36 -0500
Date: 09 Mar 98 19:00:27 -0800
From: "HNELLORE.US.ORACLE.COM" <HNELLORE@us.oracle.com>
This is regards to the unparsing of the component part and the realm
in the function
krb5_unparse_name_ext
When I have the string as oracle/hdang-sun.cisco.com@CCO.CISCO.COM
, then when krb5_unparse_name_ext parses this , it adds a '\'
character to the component part and the resulatant string for the
function who called it , (the service provider ) would look like
oracle\/hdang-sun.cisco.com@CCO.CISCO.COM
which is not the expected behaviour , Has this been fixed ?
This isn't a bug -- at least, not in krb5_unparse_name.
The backslash is escaping the forward slash character, presumably
because the principal you entered has one component, which is the string
"oracle/hdang-sun.cisco.com".
When you see something like "host/dcl.mit.edu@ATHENA.MIT.EDU", that
represents a principal with two components: "host" and "dcl.mit.edu",
and which is in the "ATHENA.MIT.EDU" realm.
I suspect that the bug is in your code that actually constructed the
krb5 principal; it generated a name with one component, when what you
really wanted was a krb5 principal name with two components, with the
first being "oracle", and the second being "hdang-sun.cisco.com".
Another way of putting this is that the "/" character is used to
separate components in Krb5 principal names. If the / character in an
actual component, it must be escaped with a backslash. Both krb5_parse
and krb5_unparse obey this convention.
So, if you passed the string "oracle\/hdang-sun.cisco.com@CCO.CISCO.COM"
to krb5_parse(), you would get the same krb5_principal that you had
started with before you called krb5_unparse(). However, the
krb5_principal represented by "oracle\/hdang-sun.cisco.com@CCO.CISCO.COM"
and "oracle/hdang-sun.cisco.com@CCO.CISCO.COM" are quite different. The
first has only one component, which contains '/' character, and the
second has two components, and the '/' character serves as a component
separator.
- Ted
State-Changed-From-To: open-closed
State-Changed-By: tytso
State-Changed-When: Tue Mar 17 17:01:07 1998
State-Changed-Why: Bug in user code, not in krb5 library routine....
This is regards to the unparsing of the component part and the realm in the
function
krb5_unparse_name_ext
When I have the string as oracle/hdang-sun.cisco.com@CCO.CISCO.COM
, then when krb5_unparse_name_ext parses this , it adds a '\'
character to the component part and the resulatant string for the
function who called it , (the service provider ) would look like
oracle\/hdang-sun.cisco.com@CCO.CISCO.COM
which is not the expected behaviour , Has this been fixed ?
If so, can you provide the version in which it is fixed or is there
a patch ?
Thanks
Hymanand
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 WAA00553 for <bugs@RT-11.MIT.EDU>; Mon, 9 Mar 1998 22:21:33 -0500
Received: from inet16.us.oracle.com by MIT.EDU with SMTP
id AA24375; Mon, 9 Mar 98 22:21:31 EST
Received: from mailsun2.us.oracle.com (mailsun2.us.oracle.com [144.25.88.74])
by inet16.us.oracle.com (8.8.5/8.8.5) with SMTP id TAA00601
for <krb5-bugs@mit.edu>; Mon, 9 Mar 1998 19:21:30 -0800 (PST)
Received: by mailsun2.us.oracle.com (SMI-8.6/37.8)
id TAA28905; Mon, 9 Mar 1998 19:31:07 -0800
Message-Id: <199803100331.TAA28905@mailsun2.us.oracle.com>
Date: 09 Mar 98 19:00:27 -0800
From: "HNELLORE.US.ORACLE.COM" <HNELLORE@us.oracle.com>
To: krb5-bugs@MIT.EDU
Cc: HNELLORE@us.oracle.com
Subject: prepending a '\'
Show quoted text
>Number: 556
>Category: pending
>Synopsis: prepending a '\'
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: gnats-admin
>State: closed
>Class: mistaken
>Submitter-Id: unknown
>Arrival-Date: Mon Mar 09 22:22:00 EST 1998
>Last-Modified: Tue Mar 17 17:01:43 EST 1998
>Originator:
>Organization:
>Release:
>Environment:
>Description:
>How-To-Repeat:
>Fix:
>Audit-Trail:
>Category: pending
>Synopsis: prepending a '\'
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: gnats-admin
>State: closed
>Class: mistaken
>Submitter-Id: unknown
>Arrival-Date: Mon Mar 09 22:22:00 EST 1998
>Last-Modified: Tue Mar 17 17:01:43 EST 1998
>Originator:
>Organization:
>Release:
>Environment:
>Description:
>How-To-Repeat:
>Fix:
>Audit-Trail:
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: krb5-bugs@MIT.EDU, "HNELLORE.US.ORACLE.COM" <HNELLORE@us.oracle.com>
Cc: gnats-admin@RT-11.MIT.EDU, krb5-prs@RT-11.MIT.EDU
Subject: Re: pending/556: prepending a '\'
Date: Tue, 10 Mar 1998 02:27:36 -0500
Date: 09 Mar 98 19:00:27 -0800
From: "HNELLORE.US.ORACLE.COM" <HNELLORE@us.oracle.com>
This is regards to the unparsing of the component part and the realm
in the function
krb5_unparse_name_ext
When I have the string as oracle/hdang-sun.cisco.com@CCO.CISCO.COM
, then when krb5_unparse_name_ext parses this , it adds a '\'
character to the component part and the resulatant string for the
function who called it , (the service provider ) would look like
oracle\/hdang-sun.cisco.com@CCO.CISCO.COM
which is not the expected behaviour , Has this been fixed ?
This isn't a bug -- at least, not in krb5_unparse_name.
The backslash is escaping the forward slash character, presumably
because the principal you entered has one component, which is the string
"oracle/hdang-sun.cisco.com".
When you see something like "host/dcl.mit.edu@ATHENA.MIT.EDU", that
represents a principal with two components: "host" and "dcl.mit.edu",
and which is in the "ATHENA.MIT.EDU" realm.
I suspect that the bug is in your code that actually constructed the
krb5 principal; it generated a name with one component, when what you
really wanted was a krb5 principal name with two components, with the
first being "oracle", and the second being "hdang-sun.cisco.com".
Another way of putting this is that the "/" character is used to
separate components in Krb5 principal names. If the / character in an
actual component, it must be escaped with a backslash. Both krb5_parse
and krb5_unparse obey this convention.
So, if you passed the string "oracle\/hdang-sun.cisco.com@CCO.CISCO.COM"
to krb5_parse(), you would get the same krb5_principal that you had
started with before you called krb5_unparse(). However, the
krb5_principal represented by "oracle\/hdang-sun.cisco.com@CCO.CISCO.COM"
and "oracle/hdang-sun.cisco.com@CCO.CISCO.COM" are quite different. The
first has only one component, which contains '/' character, and the
second has two components, and the '/' character serves as a component
separator.
- Ted
State-Changed-From-To: open-closed
State-Changed-By: tytso
State-Changed-When: Tue Mar 17 17:01:07 1998
State-Changed-Why: Bug in user code, not in krb5 library routine....
Show quoted text
>Unformatted:
Hello , This is regards to the unparsing of the component part and the realm in the
function
krb5_unparse_name_ext
When I have the string as oracle/hdang-sun.cisco.com@CCO.CISCO.COM
, then when krb5_unparse_name_ext parses this , it adds a '\'
character to the component part and the resulatant string for the
function who called it , (the service provider ) would look like
oracle\/hdang-sun.cisco.com@CCO.CISCO.COM
which is not the expected behaviour , Has this been fixed ?
If so, can you provide the version in which it is fixed or is there
a patch ?
Thanks
Hymanand