On Sat, 14 Nov 1998, Mike Jagdis wrote:
> [...] Experience
> suggests that the knowledgeable will simply hammer unforce until
> it does what they want
True, but why should they do it? Actually, in my company there isn't
such a problem: maybe hanging up the connection while someone other is
using it is not amusing enough...
Of course, the feature is intended to be used in environments like mine,
where the (internal) security is not a strict requirement. It should not
be used where some malicious user could have some reason to act.
> and the managers will just reboot the entire
> machine with the power switch (more likely several machines) :-(.
Oh, my boss could decide to do it if the line is kept connected for a TOO
LONG TIME!
> On the other hand an administrative lock mechanism which would
> log who, when, reason, allow a password to be set and would lock
> the state of the link up or down would be useful.
It would be a good thing, but I don't see a reliable way to do it without
some kind of specialized client on the remote workstation (typically
Win95/98), Perhaps a telnet session (but you have to teach the user the
commands)? Or a Java applet within an HTML frame? Mmmh... I wouldn't know
how to do it :-( .
Passwords and permissions are a good thing, but it's not trivial to
manage them, and perhaps it's not worth doing it.
I have used my patch for ten months through a simple CGI interface
program. Users connect their browsers to the firewall server, then select
the "link up" menu item and wait for connection to go up, and give the
"link down" when they finished. If someone forget giving the "link down"
command (and, truly, THIS is the only error I've seen), the line goes down
because of timeout, anyway.
Thank you for your kind message, and
Best Regards,
Giuseppe Guerrini <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
