1*7f2fe78bSCy SchubertProposed approach for passing more detailed error messages across the 2*7f2fe78bSCy Schubertkadm5 API: 3*7f2fe78bSCy Schubert 4*7f2fe78bSCy SchubertWe've already got too many init functions and too many options. 5*7f2fe78bSCy SchubertMultiplying the number of init functions isn't feasible. 6*7f2fe78bSCy Schubert 7*7f2fe78bSCy SchubertCreate an (opaque to application) init-options type, create/destroy 8*7f2fe78bSCy Schubertfunctions for it, set-creds/set-keytab/set-password functions, and a 9*7f2fe78bSCy Schubertkadm5-init-with-options function. (Optional: Reimplement the current 10*7f2fe78bSCy Schubertinit functions as wrappers around these.) 11*7f2fe78bSCy Schubert 12*7f2fe78bSCy SchubertAdd a set-context function which saves away in the init-options object 13*7f2fe78bSCy Schuberta krb5_context to be used in the new server handle instead of creating 14*7f2fe78bSCy Schuberta new one. (Destroying a server handle with such a "borrowed" krb5 15*7f2fe78bSCy Schubertcontext should probably not destroy the context.) Calls within the 16*7f2fe78bSCy Schubertlibrary should store any error messages in the context contained in 17*7f2fe78bSCy Schubertthe server handle. Error messages produced during initialization 18*7f2fe78bSCy Schubertshould also be stored in this context. 19*7f2fe78bSCy Schubert 20*7f2fe78bSCy SchubertThe caller of these functions can use krb5_get_error_message to 21*7f2fe78bSCy Schubertextract the text of the error message from the supplied context. 22*7f2fe78bSCy Schubert 23*7f2fe78bSCy SchubertUnless we determine it's safe, we should probably assert (for now) 24*7f2fe78bSCy Schubertthat each server handle must have a different context. (That's aside 25*7f2fe78bSCy Schubertfrom the thread safety issues.) 26*7f2fe78bSCy Schubert 27*7f2fe78bSCy SchubertThese contexts should have been created with kadm5_init_krb5_context, 28*7f2fe78bSCy Schubertwhich will decide whether to look at the KDC config file depending on 29*7f2fe78bSCy Schubertwhether you're using the client-side or server-side version of the 30*7f2fe78bSCy Schubertlibrary. (Same as for kadmin vs kadmin.local.) 31*7f2fe78bSCy Schubert 32*7f2fe78bSCy SchubertNotes: 33*7f2fe78bSCy Schubert 34*7f2fe78bSCy Schubert * The existing API must continue to work, without changes. There is 35*7f2fe78bSCy Schubert external code we need to continue to support. 36*7f2fe78bSCy Schubert 37*7f2fe78bSCy Schubert * We considered a variant where the application could retrieve the 38*7f2fe78bSCy Schubert error message from the server handle using a new 39*7f2fe78bSCy Schubert kadm5_get_error_message function. However, the initialization code 40*7f2fe78bSCy Schubert is one likely place where the errors would occur (can't 41*7f2fe78bSCy Schubert authenticate, etc), and in that case, there is no server handle 42*7f2fe78bSCy Schubert from which to extract the context. 43*7f2fe78bSCy Schubert 44*7f2fe78bSCy Schubert A function to retrieve the library-created krb5_context from the 45*7f2fe78bSCy Schubert server handle would have the same problem. 46*7f2fe78bSCy Schubert 47*7f2fe78bSCy Schubert Using a separate approach to deal with errors at initialization 48*7f2fe78bSCy Schubert time, in combination with the above, might work. But we still wind 49*7f2fe78bSCy Schubert up either creating the init-with-options interface or adding 50*7f2fe78bSCy Schubert error-message-return variants of multiple existing init functions. 51*7f2fe78bSCy Schubert 52*7f2fe78bSCy SchubertTo do: 53*7f2fe78bSCy Schubert 54*7f2fe78bSCy Schubert * Write up specifics (including function names -- the names used here 55*7f2fe78bSCy Schubert aren't meant to be definitive) and discuss on krbdev. 56*7f2fe78bSCy Schubert 57*7f2fe78bSCy Schubert * Implement library part. 58*7f2fe78bSCy Schubert 59*7f2fe78bSCy Schubert * Change kadmin and kdc to use it. 60