Limiting multiple logins is a feature of interest only, or at least
primarily, to ISP's which offer unlimited access accounts (which is the
topic for a whole other argument I DO NOT want to get involved in again!)
ISP's who have connect time limits or who otherwise bill for excessive
usage generally have no need for this feature. Generally speaking, that
is the distinction between people who feel that it is important and people
who don't care.
Okay, given that, there are technical issues involved in supporting it
that are non-trivial, especially in cross-platform code. To the point
where I'm almost sorry I added it. The ESVAnet hack of Livingston radiusd
was originally done for a completely different reason (I like our
interpretation of DEFAULT much better). Carl Rigney described an approach
to limiting multiple sessions that sounded easy enough to add, so I did,
but the following technical issues are unresolved at present:
1) Who is on is collected in memory by the radiusd that handles accounting
records, so the same instance of radiusd must also approve the callers.
This means that the forking model cannot be used, which places a limit on
how busy radiusd can get and still answer queries in a timely manner.
2) Due to reason (1), radiusd also cannot spend an excessive amount of
time on any given caller. This makes it difficult or impossible to
support external security devices.
3) It is possible (likely, in ComOS 3.3.1) for the accounting "stop"
record for a disconnected user to be delayed until after the caller has
redialed and tried to log in again. This causes radiusd to think that the
caller is still connected, and hence to disallow the "multiple" logon.
One answer would be to sleep for some period of time to see if a "stop"
record is received (a better alternative than an immediate refusal), but
due to reason (2) this cannot be done.
There are other minor shortcomings that I'll get to in a minute, but these
are the main problems as I see it.
The answer, or at least AN answer, is for radiusd to track current
sessions in a shared memory segment or in a file instead of in memory.
That way radiusd could use the forking model, and any given instance of
radiusd could take as long as it needed to approve a caller. (I'm
assuming that it doesn't matter if a caller times out while you're
deciding to deny access.)
Now for my problems: If I were writing this for OS/2, I would have used a
shared memory segment to hold the table right from the beginning as a
matter of course, but I don't know how to do shared memory segments in
UNIX. If I had to do it over (and it looks kinda like I do) I would use a
file, with appropriate locking to control access to the file, but I don't
know enough about the various flavors of UNIX to know if the result would
be portable. At this point I'm hoping that I can use dbopen() and flock()
and have it work most places.
Also, Livingston is beta testing a new radiusd that implements many of the
features provided by my patches. I see little point in working on code
that is about to become obsolete. My current plan is to wait until 2.0
comes out, see what it does, and patch in what features I need. When the
result looks stable, I'll release it.
Okay, as promised, other shortcomings that are (relatively) minor:
1) If a Portmaster reboots, there is a short period (a minute or two)
during which radiusd does not know that its callers are no longer
connected. When the Portmaster comes up, it sends a "start" record that
lets radiusd know that it rebooted, at which time radiusd can clear the
caller table for that Portmaster, so we're really only talking about the
time it takes a Portmaster to reboot, and reboots should be fairly
uncommon anyway.
2) If a Portmaster goes down *without* rebooting, radiusd will think all
of its callers are still connected until such time as it comes back up, or
radiusd is restarted. This is almost serious, but only almost since if it
happens you have even bigger problems anyway. Well, okay, maybe this one
wouldn't be so minor, but at least it should be rare.
3) If radiusd comes up while sessions are in progress, it will not know
about those sessions. This could cause it to allow some multiple sessions
that it should not. I regard this as minor because if you normally don't
allow multiple sessions, then your users won't normally try to have them.
Hopefully I'm correct in thinking that these last three are minor, since I
don't see any way around them. It seems to me that limiting multiple
sessions across several Portmasters requires a central dingus tracking the
sessions, meaning it has to be done in radiusd and cannot be done in the
Portmasters themselves. Or I suppose it *could* be done in the
Portmasters, but they'd still have to share data on who is connected,
leading to the exact same limitations.
One possible (though unlikely) answer would be to have radiusd query the
Portmasters about current sessions somehow. If I were to try to do that,
I'd have radiusd telnet to each Portmaster, log in as !root, and do a
"show sessions" as needed -- but that's hokey enough that I'm not going to
try to do it.
That about sums up the technical issues from my perspective, and I don't
have the cross-platform technical support problems that Livingston has.
I, for one, will be very happy when Livingston supports limiting multiple
sessions (as they've said they will), but I quite understand that it may
take them awhile!
--
("`-/")_.-'"``-._ Leo "doc" Savage
. . `; -._ )-;-,_`)
(v_,)' _ )`-.\ ``-' leo@esva.net
_.- _..-_/ / ((.'
((,.-' ((,/ http://www.esva.net/~leo/