I'm looking at solving the current issue with principals with a dot
in the first component of their name being rejected by rxkad. This
has been discussed before, and in https://lists.openafs.org/pipermail/
openafs-devel/2007-August/015388.html , a number of potential
solutions were suggested. I'm coding support for the 3rd of these
options (providing a command line configuration option to the
servers, which is propagated down to rxkad)
I've got a question about implementation strategy, however. There
needs to be a way for the server to pass configuration information
down to rxkad. At the moment all of the servers call
rxkad_NewSecurityObject to create their security object - but that
function call has no scope for embedding configuration information.
What I'm currently proposing as an implementation strategy is as
follows:
*) Add a flags variable to the rxkad_sprivate structure
*) Add a rxkad_SetFlags(struct rx_securtyClass *, int flags) function
to rxkad, which will set that variable
*) Add an argument to tkt_DecodeTicket5 to determine whether the dot
check is called
*) Modify rxkad_CheckResponse to call tkt_DecodeTicket5 with the
additional argument set based on a bit of the new flag variable, with
suitable
#defines provided.
*) Add support for calling rxkad_SetFlags() to the relevant servers,
based on their command line options.
I'd welcome comments as to the suitability of this approach.
Thanks,
Simon.
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
