[IRC-DEV] New Ideas for Operator Configuration (lista de hybrid)

Victor Roman daijo at softhome.net
Wed Mar 20 00:20:36 CET 2002


To: hybrid at the-project.org
From: Shane A. Froebel <bugs at optonline.net>
Subject: New Ideas for Operator Configuration - Hybrid 7 and above
Introduction:
This system would only work if the IRCD server is on it's own box while
connected to the net. Basically what this new O line configuration would do
is be able to read users off the system box.

These are the things the operator might be able to do:
the operator could change their password
 the operator could add a host to their profile if they go to a different
location for IRC.

A few config.h #define and #undef would need to be added.
ENABLE_OPER_SSH
o would be there to enable the ircd operator sub defines (4 below) and to
set certain parameters for allowing ircd binary to rehash the oper's file
when the oper said it was needed to.
OPER_SSH_NAME
o if the ircd chase knew this user was on the server at the moment of rehash
of their operfile was detected the server would remove his oper flags if
logged on as one.
o would read name field from file to use
OPER_SSH_USER
o would allow the user to specify their "connect" location.
OPER_SSH_HOSTMASK
o would allow the user to specify their own new hostname
 OPER_SSH_PASS
o would mean the oper can change passwords
o they would have to enter the encoded pass if that options was enabled
o the password could be the same password to connect to the machine, but
very unwise. :)
o would read password file and if none exists it uses the default one.

In the ircd.conf file the operator function would look like this if all the
options where enabled. If ENABLE_OPER_SSH is disabled, the other way would
be needed.



systemusername - System User Name needed to verify user exists.
name - This is the default nick used unless one is not given in the file
".ircd_config".
user - There would be a default host placed so the user doesn't delete all
their hosts by mistake. This would be usedbif the ".ircd_oper" file didn't
have a host to specify.
hostmask - This would be the default hostmask for the user if one was not
set in the ".ircd_config" file. The hostmask of the user would change upon
connecting to the server. The nickname would also have to match the nick
field.
password -This would be the default oper password set by irc admin if one
did not exist in the ".ircd_oper" file.


VARS:
 ** OPER_SSH_USERFILE  - global name for all the oper config file. Explained
what is in this file does above.
 EXAMPLE: OPER_SSH_USERFILE .ircd_oper




########################################
        Mock file of .ircd_oper
########################################

name="^BuGs^";
user="*bugs*@WHATEVER.NEED.AT.THE.TIME.NET";
hostmask="admin.bloops.rit.edu";
password="thisismynewpassword";

########################################
There would need to be a way to rehash just this users operator file and
making sure duplicates are not created within the ircd daemon, which could
flood the server with unnecessary operators.


Steps-by-Step in theory what would happen if I logged in on irc.rit.edu:

Connected to the server (irc.rit.edu in this case)
a. nick = ^BuGs^
b. user = bugs at res116a-067.rh.rit.edu
If ^BuGs^ is in my oper rehashed list, compare bugs at res116a-067.rh.rit.edu
with *bugs*@res116a-*.rh.rit.edu.
If they don't match, kill the user with quit message:
(Operator Nickname)
If they match works out and hostmask field is not null, change
bugs at res116a-067.rh.rit.edu to bugs at admin.bloops.rit.edu
^BuGs^ sends out "/oper ^BuGs^ thisismynewpassword" checks to make sure and
then gives out the flags out to the operator.
If OPER MOTD was defined in the config.h file, display OPER MOTD now.

Step-by-step in theory what would happen if another person named ^BuGs^
started connecting to another server that was connected to irc.rit.edu.

Connected to server (irc.flamed.net in this case)
a. nick = ^BuGs^
b. user = someass at something.aol.com
irc.rit.edu would notice that this nick is an operator on it's server and
compare the user field with it's user field for that nick.
If they don't match, irc.rit.edu would signal irc.flamed.net to kill the
user with quit message:
(Operator Nickname (irc.rit.edu --> irc.flamed.net))
If they match end "subroutine". Operator is on another server and they are
allowed to have it.






Step-by-step in theory what would happen if someone changed their nick from
Joe to ^BuGs^ on any server:

^BuGs^ and irc.servername.net would be broadcasted over the network.
irc.rit.edu would notice that this nick is an operator on it's server and
compare the user field with it's user field for that nick.
If they don't match, irc.rit.edu would signal the irc.servername.net to kill
the user with quit message: (Operator Nickname (irc.rit.edu -->
irc.servername.net))
If the user was in a channel, the quit message would be:
(Connection reset by peer)
If they match end "subroutine". Operator is on another server and they are
allowed to have it.

Conclusion remarks:

Unfortunately, this makes efnet have a global "operserv" and efnet
philosophy is that nicknames aren't reserved. But out of, 83110 (69571
Invisible Users, and 13539 Spam Targets) (grabbed from www.efnet.org) only
244 less or more are operators. That's.... 0.32% (give or take some) of
users that are operators online. That's a small chance that someone is going
to use an operator nickname unless it's very common.
So why should this be implemented then you ask? The only one I can think of
is that it would protect the operators image on the entire irc net and it
would be easier for admins because they wouldn't have to update someone's
user address every day or week. There also would be less entries in the
ircd.conf file for operators making it less crowded.
I am going to take a look at the code for ircd, but I will probably
unsuccessful if I try and implement this myself so everything here is
theoretical. Those are my ideas. Hope to hear from you soon. :)

Shane A. Froebel
CO-Admin of irc.rit.edu -- coming soon!
bugs at optonline.net (temp address)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2859 bytes
Desc: not available
URL: <http://mailman.jcea.es/pipermail/irc-dev/attachments/20020320/d005a0da/attachment.bin>


More information about the IRC-Dev mailing list