Hello Kev,
Wednesday, May 15, 2002, 4:36:57 PM, you wrote:
K> The u2.10.11 server (still in beta--we have a crash in s_conf.c somewhere)
K> allows an operator to use /opmode and /clearmode to manipulate modes on a
K> channel. Admins may wish to restrict operators from manipulating modes on
K> certain channels. Thus, I'm looking for a volunteer to implement a new
K> feature. It will be needed for the u2.10.11 release.
K> My idea is that we'll reintroduce "Q"-lines (Quarantine lines) into the
K> .conf. The first field of the Q line will contain a channel name; the
K> second field will include a text message to be spat back to any operator
K> attempting to manipulate modes on that channel via /opmode or /clearmode.
K> I don't expect there to be many of these lines, so for a first cut, a
K> straight linked list is sufficient. I don't anticipate any other fields
K> being necessary.
K> Currently, operators can use /opmode or /clearmode if they have the
K> PRIV_OPMODE. This feature would require addition of a PRIV_FORCE_OPMODE,
K> to allow operators to override the Q-line restriction if need be. Because
K> u2.10.11's .conf does not support privileges (u2.10.12's does), a feature
K> will also be needed: FEAT_OPER_FORCE_OPMODE. I will leave it to your
K> discretion whether to allow local channels ("&" prefix) to be specified in
K> Q-lines--if you decide to implement this, PRIV_FORCE_LOCAL_OPMODE and
K> FEAT_OPER_FORCE_LOPMODE and FEAT_LOCOP_FORCE_LOPMODE will also be needed.
K> Finally, mo_opmode() and mo_clearmode() (NOT ms_opmode() or
K> ms_clearmode()!) will need to be modified to check Q-lines. If the
K> channel name is prefixed by a "!", then Q-lines will not be checked, but
K> the appropriate privilege (PRIV_FORCE_OPMODE or PRIV_FORCE_LOCAL_OPMODE)
K> must be checked. If the oper is attempting to use "!" to force the mode
K> change, and does not have the FORCE privilege, respond with
K> ERR_NOPRIVILEGES.
K> You may also, at your discretion, change the text of the ERR_NOPRIVILEGES
K> error message to reflect its current use--the current text says, "You're
K> not an IRC operator," but something like "You don't have permission to do
K> that" may be more appropriate.
K> As a final note, you must make certain that the documentation in
K> doc/example.conf and doc/readme.features is brought up to date with your
K> changes.
K> If you're interested in working on this, post here to the list. If more
K> than one person is interested, I would encourage all of you to collaborate.
K> Feel free to ask me questions, though I should note that my time is going
K> to be rather limited over the next few weeks). Please post diffs to
K> [EMAIL PROTECTED], but keep commentary on this list. Even if the diff
K> is not a final product, please make sure that it includes ChangeLog
K> documentation and a short description appropriate for a commit message.
K> Do feel free to add your name(s) to doc/Authors in an appropriate place.
K> Thanks,
Kev, I'm not sure, but shouldn't this be limited to local channels
only ? Otherwise you could get fights between admins and servers, and
I doubt you folks would want that.
My other question regarding this is: Why would you want to limit
opmode's in certain channels ?
Smells the same to me like CSC thinks about certain features in
gnuworld: Trustworthyness of an oper.
If an admin wants to know whats done by his oper on the server he can tell his
opers not to touch certain channels, and instead of Q: lines I'd
rather propose hacklogging. With some little parse scripts an admin
could make him warn through email if someone evades his decisions.
Less CPU usage I guess.
--
Best regards,
OUTsider mailto:[EMAIL PROTECTED]
P.S. In case this mail is HTML, this is done accidentially. Testing my new
email client (The Bat) and need to configure it a bit.
