From bjaspan@MIT.EDU Fri Nov 1 10:56:41 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 KAA16690 for <bugs@RT-11.MIT.EDU>; Fri, 1 Nov 1996 10:56:41 -0500
Received: from DUN-DUN-NOODLES.MIT.EDU by MIT.EDU with SMTP
id AA08832; Fri, 1 Nov 96 10:56:40 EST
Received: by DUN-DUN-NOODLES.MIT.EDU (5.x/4.7) id AA06094; Fri, 1 Nov 1996 10:56:35 -0500
Message-Id: <9611011556.AA06094@DUN-DUN-NOODLES.MIT.EDU>
Date: Fri, 1 Nov 1996 10:56:35 -0500
From: bjaspan@MIT.EDU
Reply-To: bjaspan@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: filter tl_data types < 256
X-Send-Pr-Version: 3.99
System: SunOS DUN-DUN-NOODLES 5.4 Generic_101945-37 sun4m sparc
Marc has proposed semantics for the tl_data type namespace in which
all types < 256 are reserved for "internal use" by Kerberos and thus
cannot be defined by applications, I agree, and no one else has
complained. Therefore, (a) document it, and (b) make get_principal
and modify_principal filter out those types so kadm5 clients never see
them and cannot set them.
State-Changed-From-To: open-closed
State-Changed-By: bjaspan
State-Changed-When: Fri Nov 1 13:21:13 1996
State-Changed-Why:
Fixed. Files:
doc/kadm5/api-funcspec.tex
doc/kadm5/api-unit-test.tex
lib/kadm5/ChangeLog
lib/kadm5/unit-test/ChangeLog
lib/kadm5/srv/ChangeLog
kadmin/testing/ChangeLog
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 KAA16690 for <bugs@RT-11.MIT.EDU>; Fri, 1 Nov 1996 10:56:41 -0500
Received: from DUN-DUN-NOODLES.MIT.EDU by MIT.EDU with SMTP
id AA08832; Fri, 1 Nov 96 10:56:40 EST
Received: by DUN-DUN-NOODLES.MIT.EDU (5.x/4.7) id AA06094; Fri, 1 Nov 1996 10:56:35 -0500
Message-Id: <9611011556.AA06094@DUN-DUN-NOODLES.MIT.EDU>
Date: Fri, 1 Nov 1996 10:56:35 -0500
From: bjaspan@MIT.EDU
Reply-To: bjaspan@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: filter tl_data types < 256
X-Send-Pr-Version: 3.99
Show quoted text
>Number: 140
>Category: krb5-admin
>Synopsis: filter tl_data types < 256
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bjaspan
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Fri Nov e 10:57:00 EST 1996
>Last-Modified: Fri Nov e 13:26:50 EST 1996
>Originator: Barry Jaspan
>Organization:
mit>Category: krb5-admin
>Synopsis: filter tl_data types < 256
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bjaspan
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Fri Nov e 10:57:00 EST 1996
>Last-Modified: Fri Nov e 13:26:50 EST 1996
>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:
Marc has proposed semantics for the tl_data type namespace in which
all types < 256 are reserved for "internal use" by Kerberos and thus
cannot be defined by applications, I agree, and no one else has
complained. Therefore, (a) document it, and (b) make get_principal
and modify_principal filter out those types so kadm5 clients never see
them and cannot set them.
Show quoted text
>How-To-Repeat:
Show quoted text
>Fix:
Show quoted text
>Audit-Trail:
State-Changed-From-To: open-closed
State-Changed-By: bjaspan
State-Changed-When: Fri Nov 1 13:21:13 1996
State-Changed-Why:
Fixed. Files:
doc/kadm5/api-funcspec.tex
doc/kadm5/api-unit-test.tex
lib/kadm5/ChangeLog
lib/kadm5/unit-test/ChangeLog
lib/kadm5/srv/ChangeLog
kadmin/testing/ChangeLog
Show quoted text
>Unformatted: