blob: c12bfe67f3580bd8f9e8119c9de885835e23792f (
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
|
- How to handle mixed proxied and non-proxied credentials for one
process?
Idea #0: Always use the proxy or no proxy. Period. Use an env var to
select mechglue config.
Idea #1: Some mechglue magic and minor constraints on the applications.
- mechglue needs to allow multiple providers to provide same
mechanisms, with GSS_Acquire/Add_cred*() trying all providers for
the desired mechanism(s) in order till one works or all fail;
- this does not work for GSS_Init/Accept_sec_context() when using
the default credential;
- for GSS_Init_sec_context() just pick one provider to be first
for default credential and let apps that want the other
provider acquire a credential handle instead of using the
default one (e.g., ssh -o GSSAPIInitiatorCredential=...);
- for GSS_Accept_sec_context() declare that all acceptor
credentials for any given mechanism must be proxied or not;
Idea #2: Use PGSS or GSS-APIv3 so we can have a caller context handle
via which to specify mechglue configuration.
- SPNEGO (any pseudo-mechanism) should not be proxied, as it will
re-enter the mechglue and call the proxy(ies) if needed (or not) as
appropriate.
- How to pass around ccaches ?
We simply don't.
1. For a user, we should probably deny init_sec_context initially, but if we
allow it we need to create a ccache like
/var/lib/gssproxy/cc/krb5cc_<userename>
The user will not have direct access to the cache.
2. For a normal service we will do the same, both accept and init contetx use
the configured keytab and the ccache will be in
/var/lib/gssproxy/cc/krb5cc_<servicename>
3. For a trusted service we do the same as in 2. except when the service
asks us to init_sec_context as a user, in that case we will try to use the
user's ccache in /run/user/<username>/krb5cc, erroring out if it does not
exist or is expired.
|
