[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Most recent version of the FAQ?
>>>>> "Kurt" == Kurt Roeckx <Q@xxxxxxx> writes:
Jack> I'm looking for a real simple table lookup situation, and it's
Jack> my home that the user won't be able to do anything on my ircd if
Jack> it hasn't authenticated. Is this unreasonable?
Kurt> Looking a user and pass up in some table should be pretty easy.
It's not the table lookup that I'm worried about. :-)
Kurt> The module can reject clients, by sending it to ircd, and then
Kurt> make iauth stop authenticate it, by setting an option on the
Kurt> client data.
Jack> Ooooh. I'd love to see a simple functional example.
Kurt> It already does it...
[... code example elided ...]
Okay, this helps a lot.
Kurt> It's just the same like all other modules in iauth work.
Jack> See, this helps me not. The docs weren't too useful for me,
Jack> unfortunately.
Kurt> Did you read iauth-internals.txt? If that didn't help, try
Kurt> reading some of the other modules, or ask.
Hmmm. That looks useful. Let me try to explain my goal in English,
and then try to describe how I'd make iauth do the right thing.
Basically, I want to remove identd checking and use my own custom
checking as the sole authentication method. All users will have to
submit a username and password. There exists a C function that, given
said username and password, gives a yes or no answer. If the answer
is no, the user is removed, preferably with a message.
passwd_init will send the following to the ircd:
A * passwd
s
O RTA
>passwd_init successful
passwd_release will send the following to the ircd:
>passwd_release successful
passwd_stats will send the following to the ircd:
S passwd connected 0 badname 0 badpasswd 0 out of 0
passwd_start will send the following to the ircd:
(success)
U 2 192.168.2.10 13578 earthpig
D 2 203.36.167.162 13578
(failure)
I 2 203.36.167.162 13578 NOTICE AUTH :Bad password
>client from 203.36.167.162:13578 denied: Bad password
K 2 203.36.167.162 13578
D 2 203.36.167.162 13578
passwd_work and passwd_clean wouldn't do anything.
passwd_timeout would always act like passwd_start failing.
passwd_load would read in the table.
Is this right?
Jack> * what known security holes exist in ircd 2.10.3?
Kurt> There are no known security holes.
Jack> Great. What's the process when one comes up? Do you guys
Jack> notify the list when the problem's reported, when it's verified,
Jack> when it's fixed, anything like that?
Kurt> It depends on the bug.
Kurt> There are cases where we send mail to ircd-users@xxxxxxx as soon
Kurt> as we have a fix or workaround for it, like last time.
Kurt> There are other cases where we first mail the opers of IRCnet
Kurt> (the primary net that uses this ircd), with the fix. This is to
Kurt> prevent the whole net from being DoS'd (or hacked). The list
Kurt> will be mailed at a later time then.
Okay. If this test works, and the company decides to go with ircd as
a mission-critical tool, I'd like to be added to the magic list if at
all possible.
Kurt> Kurt
--
Jack Twilley
jmt at tbe dot net
http colon slash slash www dot tbe dot net slash tilde jmt slash