Re: Thanks for your advices!

On Thu, 18 Nov 2004, Sergey Poznyakoff wrote:

First, I promise this is my last E-mail with questions about this
without reading the full RFCs in question. :-) One thing I did catch
from a first run through though in Operation: "Retry and fallback
algorithms are the topic of current research and are not specified in
detail in this document." In fairness that may be referring more to
fallback of other radius servers. That's the only place I could find
mention of fallback in 2865 though.

I'm also moving topics around so related stuff is together. (A bit more
than just in-line and snipping.)

> DEFAULT	   Auth-Type = SQL,

This example is really good because it allows me to point out why I
think gnu-radius could do more here. I know gnu-radius doesn't establish
the connection to the database once it reaches this line, but as you
mentioned "Both Auth-Type and Simultaneous-Use are internal attributes"
where internal means only for use of gnu-radius. Parsing through the
users file we should stop right here and say we can't match this DEFAULT
entry since we can't contact the Auth-Type. In order of the statements
within the DEFAULT entry we could stop here if the database connection
isn't established or can't be maintained.

> It's not that I'm contrary to the idea of back-up authentication
> methods, but implementing them this way does not seem to be
> acceptable. I will gladly discuss any propositions/ideas.

I guess my practical suggestion would be putting the stipulation back
on the end user administrator of the gnu-radius software. If the
admin wants users file database fail-over behavior, gnu-radius could
require the use of pconnects to the database along with an option that
says you want this feature... (I'm using DBI terminology, pconnect
being persistent connections instead of connections established as
needed. c/cpp/gcc uses the same name?) gnu-radius could then exempt
a users file entry that points to a database before it gets to the
matching Access-Request details ...when the pconnect fails or can't be
brought up. I would think hooks near or around persistent connections
might be the easiest way to make this another option from a coding
perspective. This would seem to me to still fit the RFC since we could
say we excluded the users entry based on Internal invalid attributes.
(Error: "Auth-Type = SQL" invalid; Connection to the database can not
be established or maintained. Check the database server, or sqlserver
file.)

> II) Any conditions implied by internal attributes found in the entry
> must be met (e.g. Auth-Type, whatever it is, must succeed

This seems to support my interpretation.

This doesn't have to preclude continuing attempts to establish a
connection to the database. It just seems an easy way we can use
internal attributes to create this behavior as an option.

> The setup Konst wishes to implement seems to be the worst case: you
> may log in with *any* username and *any* password while the db server
> is down.

I agree with you completely here. Had you not replied, I was going to
point out how much of a bad idea his solution was. Having the system
password file as a backup to mysql is one thing, but just authenticating
all requests if the DB is down is a patently bad idea. Denial of Service
vulnerabilities are more common than remote roots. DoS'ing the database
shouldn't open up your authentication system facilitating remote root on
whatever relies on RADIUS.

> :^)) [Guile's] way faster than firing an external program.

I agree. Guile seems to say if you don't like the code the way it is,
write your own module. I don't know if some people that write to the
list know how lucky they are that you give practical suggestions within
the guile implementation instead of just pointing to guile and saying,
you can do it that way.

Gerald