From: Jeremy Rumpf (jrumpf at heavyload dot net)
Date: Thu Mar 25 2004 - 11:24:07 EST
[snip]
> I believe that each authentication mech needs to deal with userid/realm
> params in their own way (just like auxprop plugins do). Although your
> proposal should work as well, we also need to deal with the realm value
> (pass it as is, alter it, ignore it, etc..)
Yea, I've been thinking about that more. I realized my misjudgement that some
of the mechs have no concept of a realm. They should possibly concat them
internally in their own manner. That way something coming down the pipeline
as:
user: foo
realm: bar
Is at least useable via PAM, etc. as foo at bar dot
>
> In my opinion, sasl lib should not alter the username to begin with;
> user at domain dot tld is a perfectly valid userid. In addition non of the
> plaintexts mech have use for the realm value like gssapi and digest-md5
> mechs do.
>
I agree as well. At this point it seems odd to have sasl split foo at bar dot com up
into username/realm components and then have auth_pam reassemble them, but if
that is the best compromise it seems sensible.
> https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2326
>
> > I would also be interesting to know the rationale for changin SASL's
> > behavior.
>
> http://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2094
char user[256];
might be best to do
char user[MAX_REQ_LEN * 2]
(MAX_REQ_LEN in saslauth-main.h) or something. Currently MAX_REQ_LEN is 256,
so the max length would be 512 plus some change for the @ and NULL.
Thanks for the bugzilla links,
Jeremy
|
|
|