Modified the Sphinx HTML page layout
[krb5.git] / doc / iprop-notes.txt
index 2b1ee43c20132dc3b0d01fdfb505ea35d14e2ed4..8efee36f6610d33489385ba204f77b5eb2e1c53e 100644 (file)
@@ -10,6 +10,14 @@ for the kprop.  If the connection from the master never comes in for
 some reason, the slave side just blocks forever, and never resumes
 incremental propagation.
 
+The protocol does not currently pass policy database changes; this was
+an intentional decision on Sun's part.  The policy database is only
+relevant to the master KDC, and is usually fairly static (aside from
+refcount updates), but not propagating it does mean that a slave
+maintained via iprop can't simply be promoted to a master in disaster
+recovery or other cases without doing a full propagation or restoring
+a database from backups.
+
 Shawn had a good suggestion after I started the integration work, and
 which I haven't had a chance to implement: Make the update-log code
 fit in as a sort of pseudo-database layer via the DAL, being called
@@ -118,3 +126,15 @@ it in debug mode ("-d").  You'll still lose all output from the
 invocation of kdb5_util dump and kprop run out of kadmind.
 
 Other man page updates needed: Anything with new -x options.
+
+Comments from lha:
+
+Verify both client and server are demanding privacy from RPC.
+
+Authorization code in check_iprop_rpcsec_auth is weird.  Check realm
+checking, is it trusting the client realm length?
+
+What will happen if my realm is named "A" and I can get a cross realm
+(though multihop) to ATHENA.MIT.EDU's iprop server?
+
+Why is the ACL not applied before we get to the functions themselves?