|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Message-ID: <d1d783df-7267-4baa-8359-133ca78a6fe5@mit.edu> Date: Wed, 27 Nov 2024 00:00:08 -0500 MIME-Version: 1.0 To: Andreas Schneider <asn@samba.org>, krbdev@mit.edu Content-Language: en-US From: "Greg Hudson" <ghudson@mit.edu> In-Reply-To: <2413859.cojqenx9y0@magrathea> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: krbdev-bounces@mit.edu On 11/26/24 06:28, Andreas Schneider via krbdev wrote: > Alexander and I came up with the idea to write a new module but use the klmdb > module as a base. This way we just need to implement put_principal and > get_principal to handle passwd accounts and for all the rest use klmdb. Also > we need to add PAC with SIDs. > > In order to get that working we would need a public function like > kdb_find_library(), kdb_lib_get_vftbl() and free function. Short answer: I think this is a reasonable starting point, and if I have any concerns about the specifics we can discuss them in the PR. Long answer: I can see two basic approaches to make KDB modules stackable. The first approach (and the one suggested above) is reentrancy, where the outer module can call back into libkdb5 to consume the methods of a different inner module. The second approach I'll call accumulation: multiple KDB modules could be configured, and each libkdb5 function would combine the results of the modules. The reentrancy approach is innately flexible, from the outer module's perspective--any transformation of the inner module's behavior is possible. Achieving that flexibility in the accumulation approach might require amendments to method signatures. Reentrancy is also probably the easier approach. The reentrancy approach does have some costs, which mostly take the form of additional boilerplate in stacking modules: 1. The outer module must implement every method the inner module does. 2. Because we overload krb5_context as a DB handle, the outer module will have to manage a second context object to call into libkdb5. 3. The outer module will be responsible for selecting and loading the inner module. Since burden of these costs is borne by the stacking modules (i.e. not the MIT krb5 code) and we have the freedom to change approaches in the future, I am fine with the reentrancy approach. _______________________________________________ krbdev mailing list krbdev@mit.edu https://mailman.mit.edu/mailman/listinfo/krbdev
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |