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