[1914] in Kerberos_V5_Development
Re: Cygnus changes for your consideration
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Thu Oct 31 12:58:36 1996
Date: Thu, 31 Oct 1996 12:57:51 -0500
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: eichin@cygnus.com
Cc: tytso@MIT.EDU, krbdev@MIT.EDU
In-Reply-To: <xe1ybgnkp5b.fsf@maneki-neko.cygnus.com> (message from Mark
Eichin on 31 Oct 1996 12:41:04 -0500)
the "dbutil locking trick" is the changes Barry and I talked about
earlier: fixing unlock so it only closed the database on the last
unlock, ditching the ifdefs, and then having dbutil grab a lock on
db~ (ie. the primary database) if !update so that it doesn't get
reopened/closed after each record
Ah... so this only affects handling the kdb layer, right? In that
case, it should not conflict with the policy database changes I made.
> + kadmin/cli x9 and tl_data changes (in support of X9.9 token devices)
two parts: some bugfixes to lib/kadm5 (mostly server side I think) so
that it didn't fall over when handed more than one tl_data record
(which from some recent commits you may already have fixed, I have to
look, these are based on diffs from a couple of weeks ago)
Yes, I discovered that the tl_data handling was completely wrong.
kadm5_modify_principal tried to splice together what was already there
and what was given as input, which (a) it did wrong and (b) even if it
did right, was the wrong semantics. Now it just replaces all the
principal's tl_data with what was given as input, with the exception
that KRB5_TL_KADM5_DATA is always added by kdb_put_entry (and,
consequently, ignored if it is specified as input). This is the right
because kadm5_get_principal always returns all the tl_data entries to
a caller, not just the entries the caller is interested in, so if
kadm5_modify_principal were to combine what was given and what was
already present you'd end up with duplicates of everything. This
means that a caller that wants to set tl_data must always call
get_principal first, and be sure to pass everything back to
modify_principal, not just its own record.
I guess this might be considered a pain in some cases. If so, we
could add a new mask option, KADM5_TL_DATA_APPEND, which tells modify
to add the tl_data input to what is there instead of replacing the
entire list. Then the caller would be responsible for *only* passing
in a new record, not all of the old records returned by get_principal.
Furthermore, modify_principal would then have to scan through the
tl_data list and remove existing entries of the type being appended.
But then that functionality would preclude the use of tl_data types
that are supposed to have multiple entries, whereas the current
semantics (having the caller specify the complete tl_data list) does
not.
All this boils down to the fact that, IMHO, the current semantics
(replacing tl_data) are right. Did anyone even follow the argument
this far? :-)
Barry
