kadmind authorization design choices
simo at redhat.com
Thu Jun 15 11:38:30 EDT 2017
On Tue, 2017-06-13 at 13:36 -0400, Greg Hudson wrote:
> I have started work on making kadmind authorization more flexible,
> probably by adding a new pluggable interface. The early project page is
> There are two design choices I would like input on before I get too far
> into this work:
> 1. Currently the kadm5.acl processing code lives in kadm5srv, but is
> only called from kadmind. I would like to move that code into kadmind
> and make it one module within a pluggable interface consumed by kadmind.
> However, a developer on IRC raised the possibility that someone invoking
> kadmin.local (or another libkadm5srv application) might want to
> voluntarily apply the permissions for a client principal, as it might be
> performing on operation on that client's behalf. To support this use
> case, we would likely need to move the code that performs authorization
> checks from kadmind into libkadm5srv, in which case having moved the
> code out of libkadm5srv would seem like an error.
I do not think moving to libkadm5srv is that compelling.
> My question is: how important is this use case? It would likely take a
> fair amount of work to make libkadm5srv handle the authorization checks,
> and if we're never going to get around to it, YAGNI applies. But if
> this is an important need that we've simply been neglecting, I'd like to
They can always use kadmin even when operating on the local host, so I
am not sure how useful it is to have to fake things in kadmin.local ...
can't really judge w/o hearing the reasons for such "emulation".
> 2. If you were implementing a module for this new authz interface, would
> you rather:
> * Implement one megamethod, with an opcode (with around 15 possible
> values) and several parameters, not all of which are applicable to all
> * Implement roughly fifteen methods, where the operation is part of the
> method name, and the parameters depend on the opcode
I prefer this one for implementation purposes as it allows to break
things in smaller steps and test each function independently.
> * Implement 3-5 methods for different classes of opcodes (e.g. principal
> operations, policy operations, and general operations), where each
> method has an opcode and parameters dependent on the opcode class
> I think all of these options can be made properly extensible, so this is
> mostly a matter of preference.
I think it is also a matetr of readability and better debuggability.
for example in gdb catching a specific function w/o having to manually
waive "other uses" can be really useful if you want to step into a
specific authz step in a process that is going through many steps.
Sr. Principal Software Engineer
Red Hat, Inc
More information about the krbdev