"Fossies" - the Fresh Open Source Software Archive

Member "krb5-1.18/doc/iprop-notes.txt" (12 Feb 2020, 6779 Bytes) of package /linux/misc/krb5-1.18.tar.gz:

As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file. For more information about "iprop-notes.txt" see the Fossies "Dox" file reference documentation and the last Fossies "Diffs" side-by-side code changes report: 1.16.3_vs_1.17.

    1 Some (intentional) changes from Sun's submission are noted in the
    2 install guide.
    4 Bugs or issues:
    6 The "full resync" part of the protocol involves the master side firing
    7 off a normal kprop (and going back to servicing requests), and the
    8 replica side stopping all the incremental propagation stuff and
    9 waiting for the kprop.  If the connection from the master never comes
   10 in for some reason, the replica side just blocks forever, and never
   11 resumes incremental propagation.
   13 The protocol does not currently pass policy database changes; this was
   14 an intentional decision on Sun's part.  The policy database is only
   15 relevant to the master KDC, and is usually fairly static (aside from
   16 refcount updates), but not propagating it does mean that a replica
   17 maintained via iprop can't simply be promoted to a master in disaster
   18 recovery or other cases without doing a full propagation or restoring
   19 a database from backups.
   21 Shawn had a good suggestion after I started the integration work, and
   22 which I haven't had a chance to implement: Make the update-log code
   23 fit in as a sort of pseudo-database layer via the DAL, being called
   24 through the standard DAL methods, and doing its work around calls
   25 through to the real database back end again through the DAL methods.
   26 So for example, creating a "iprop+db2" database would create an update
   27 log and the real db2 database; storing a principal entry would update
   28 the update log as well; etc.  At least initially, we wouldn't treat it
   29 as a differently-named database; the installation of the hooks would
   30 be done by explicitly checking if iprop is enabled, etc.
   32 The "iprop role" is assumed to be either master or replica.  The
   33 master writes a log, and the replica fetches it.  But what about a
   34 cascade propagation model where A sends to B which sends to C, perhaps
   35 because A's bandwidth is highly limited, or B and C are co-located?
   36 In such a case, B would want to operate in both modes.  Granted, with
   37 iprop the bandwidth issues should be less important, but there may
   38 still be reasons one may wish to run in such a configuration.
   40 The propagation of changes does not happen in real time.  It's not a
   41 "push" protocol; the replicas poll periodically for changes.  Perhaps
   42 a future revision of the protocol could address that.
   44 kadmin/cli/kadmin.c call to kadm5_init_iprop - is this needed in
   45 client-side program? Should it be done in libkadm5srv instead as part
   46 of the existing kadm5_init* so that database-accessing applications
   47 that don't get updated at the source level will automatically start
   48 changing the update log as needed?
   50 Locking: Currently DAL exports the DB locking interface to the caller;
   51 we want to slip the iprop code in between -- run it plus the DB update
   52 operation with the DB lock held, whether or not the caller grabbed the
   53 lock.  (Does the caller always grab the lock before making changes?)
   54 Currently we're using a file lock on the update log itself; this will
   55 be independent of whether the DB back end implements locking (which
   56 may be a good thing or a bad thing, depending).
   58 Various logging calls with odd format strings like "<null>" should be
   59 fixed.
   61 Why are different principal names used, when incremental propagation
   62 requires that normal kprop (which uses host principals) be possible
   63 anyways?
   65 Why is this tied to kadmind, aside from (a) wanting to prevent other
   66 db changes, which locking protocols should deal with anyways, (b)
   67 existing acl code, (c) existing server process?
   69 The incremental propagation protocol requires an ACL entry on the
   70 master, listing the replica.  Since the full-resync part uses normal
   71 kprop, the replica also has to have an ACL entry for the master.  If
   72 this is missing, I suspect the behavior will be that every two
   73 minutes, the master side will (at the prompting of the replica) dump
   74 out the database and attempt a full propagation.
   76 Possible optimizations: If an existing dump file has a recent enough
   77 serial number, just send it, without dumping again?  Use just one dump
   78 file instead of one per replica?
   80 Requiring normal kprop means the replica still can't be behind a NAT
   81 or firewall without special configuration.  The incremental parts can
   82 work in such a configuration, so long as outgoing TCP connections are
   83 allowed.
   85 Still limited to IPv4 because of limitations in MIT's version of the
   86 RPC code.  (This could be fixed for kprop, if IPv6 sites want to do
   87 full propagation only.  Doing incremental propagation over IPv6 will
   88 take work on the RPC library, and probably introduce
   89 backwards-incompatible ABI changes.)
   91 Overflow checks for ulogentries times block size?
   93 If file can't be made the size indicated by ulogentries, shoud we
   94 truncate or error out?  If we error out, this could blow out when
   95 resizing the log because of a too-large log entry.
   97 The kprop invocation doesn't specify a realm name, so it'll only work
   98 for the default realm.  No clean way to specify a port number, either.
   99 Would it be overkill to come up with a way to configure host+port for
  100 kpropd on the master?  Preferably in a way that'd support cascading
  101 propagations.
  103 The kadmind process, when it needs to run kprop, extracts the replica
  104 host name from the client principal name.  It assumes that the
  105 principal name will be of the form foo/hostname@REALM, and looks
  106 specifically for the "/" and "@" to chop up the string form of the
  107 name.  If looking up that name won't give a working IPv4 address for
  108 the replica, kprop will fail (and kpropd will keep waiting,
  109 incremental updates will stop, etc).
  111 Mapping between file offsets and structure addresses, we should be
  112 careful about alignment.  We're probably okay on current platforms,
  113 but if we break log-format compatibility with Sun at some point, use
  114 the chance to make the kdb_ent_header_t offsets be more strictly
  115 aligned in the file.  (16 or 32 bytes?)
  117 Not thread safe!  The kdb5.c code will get a lock on the update log
  118 file while making changes, but the lock is per-process.  Currently
  119 there are no processes I know of that use multiple threads and change
  120 the database.  (There's the Novell patch to make the KDC
  121 multithreaded, but the kdc-kdb-update option doesn't currently
  122 compile.)
  124 Logging in kpropd is poor to useless.  If there are any problems, run
  125 it in debug mode ("-d").  You'll still lose all output from the
  126 invocation of kdb5_util dump and kprop run out of kadmind.
  128 Other man page updates needed: Anything with new -x options.
  130 Comments from lha:
  132 Verify both client and server are demanding privacy from RPC.
  134 Authorization code in check_iprop_rpcsec_auth is weird.  Check realm
  135 checking, is it trusting the client realm length?
  137 What will happen if my realm is named "A" and I can get a cross realm
  138 (though multihop) to ATHENA.MIT.EDU's iprop server?
  140 Why is the ACL not applied before we get to the functions themselves?