From bjaspan@MIT.EDU Wed Oct 9 18:14:45 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 SAA24118 for <bugs@RT-11.MIT.EDU>; Wed, 9 Oct 1996 18:14:45 -0400
Received: from DUN-DUN-NOODLES.MIT.EDU by MIT.EDU with SMTP
id AA10480; Wed, 9 Oct 96 18:14:44 EDT
Received: by DUN-DUN-NOODLES.MIT.EDU (5.x/4.7) id AA18261; Wed, 9 Oct 1996 18:14:40 -0400
Message-Id: <9610092214.AA18261@DUN-DUN-NOODLES.MIT.EDU>
Date: Wed, 9 Oct 1996 18:14:40 -0400
From: bjaspan@MIT.EDU
Reply-To: bjaspan@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: dump/load inter-version inconsistencies
X-Send-Pr-Version: 3.99
System: SunOS DUN-DUN-NOODLES 5.4 Generic_101945-37 sun4m sparc
The beta 6 database format contains tagged data, so the beta 6 dump
format also contains them. Therefore, kdb5_util dump -b6 dumps all
the tagged data, including the record that contains a principal's
policy and password history information. If someone dumps a b6
database, then loads it back in with kdb5_util load, the policy
records will be lost (because b6 didn't contain them), but the
principal's pointers to the policies will be preserved.
The solution is probably for kdb5_util dump -b6 not to dump the KADM5
tagged data, since it knows for a fact tath the b6 database won't do
anything with it.
State-Changed-From-To: open-closed
State-Changed-By: bjaspan
State-Changed-When: Fri Oct 18 16:11:12 1996
State-Changed-Why:
Fixed. Files:
kadmin/dbutil/ChangeLog
kadmin/dbutil/dump.c
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 SAA24118 for <bugs@RT-11.MIT.EDU>; Wed, 9 Oct 1996 18:14:45 -0400
Received: from DUN-DUN-NOODLES.MIT.EDU by MIT.EDU with SMTP
id AA10480; Wed, 9 Oct 96 18:14:44 EDT
Received: by DUN-DUN-NOODLES.MIT.EDU (5.x/4.7) id AA18261; Wed, 9 Oct 1996 18:14:40 -0400
Message-Id: <9610092214.AA18261@DUN-DUN-NOODLES.MIT.EDU>
Date: Wed, 9 Oct 1996 18:14:40 -0400
From: bjaspan@MIT.EDU
Reply-To: bjaspan@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: dump/load inter-version inconsistencies
X-Send-Pr-Version: 3.99
Show quoted text
>Number: 89
>Category: krb5-admin
>Synopsis: dump/load inter-version inconsistencies
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bjaspan
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Wed Oct e 18:15:01 EDT 1996
>Last-Modified: Fri Oct e 16:11:33 EDT 1996
>Originator: Barry Jaspan
>Organization:
mit>Category: krb5-admin
>Synopsis: dump/load inter-version inconsistencies
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bjaspan
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Wed Oct e 18:15:01 EDT 1996
>Last-Modified: Fri Oct e 16:11:33 EDT 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:
The beta 6 database format contains tagged data, so the beta 6 dump
format also contains them. Therefore, kdb5_util dump -b6 dumps all
the tagged data, including the record that contains a principal's
policy and password history information. If someone dumps a b6
database, then loads it back in with kdb5_util load, the policy
records will be lost (because b6 didn't contain them), but the
principal's pointers to the policies will be preserved.
The solution is probably for kdb5_util dump -b6 not to dump the KADM5
tagged data, since it knows for a fact tath the b6 database won't do
anything with it.
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 Oct 18 16:11:12 1996
State-Changed-Why:
Fixed. Files:
kadmin/dbutil/ChangeLog
kadmin/dbutil/dump.c
Show quoted text
>Unformatted: