Hello I wonder If your Team can code so SOps can't get BANNED & OR KICKED from the channel that will help alot. What do you say?
Yôù`££ Nêvêr ßê £îKê Mê
_________________________________________________________________ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx
It's not a bad idea, and would curtail or discourage certain abuses, but it's also not a trivial proposition. For IRC servers to make decisions based on channel access as recorded by agents like ChanServ, they have to know more than they currently know.
It requires either services annotate the channel state, i.e. indicate "why it ops" someone, what level they have, and all servers pass it along, which requires good synchronization.
Or a Request-Approve-Act cycle occur whenever someone attempts to kick/deop someone (Query services or an agent synchronized with services [such as a slave database server] for approval, execute the request only after approval)
The latter solution presents scalability issues, and system degradation -- do you want to wait 60 extra seconds for services to confirm your deop/kick before you can de-op/ban a channel hijacker? I think not.
For it to be effective, there would have to be servers to provide authoritative answers at low latency to every single IRC server.
The former solution presents a lot of problems like -- what happens when access level changes. Maybe ChanServ didn't op the SOP originally... i.e. someone else opped them, and they identified with NickServ after the fact.
Then extra traffic is required to attempt to push an 'update' to the channel state, indicating the change of identified level.
These are all mainly services development matters. The feasibility of implementation depends on the design of services. The cost depends on the protocol methods chosen.
And I doubt there are many services developers available to implement something like this.
Or at least in the past there haven't been....
On Sun, Apr 12, 2009 at 9:02 AM, BILaL Bhatty expl0iter@live.com wrote:
Hello I wonder If your Team can code so SOps can't get BANNED & OR KICKED from the channel that will help alot. What do you say?
-- -J
BILaL Bhatty wrote:
Hello I wonder If your Team can code so SOps can't get BANNED & OR KICKED from the channel that will help alot. What do you say?
Notwithstanding the technical challenges that James mentioned, I would say that this should be a matter of policy. If people are getting opped via other users or via the aop list and are causing problems for the sops, then actions should be taken to prevent those users from getting ops.
If an Sop nick were to be compromised, the channel ops would no longer be able to handle the situation on their own, since that person would be unkickable and unbannable.
This just isn't realistic, and it wouldn't really solve the problem. People would just seek to compromise sop nicks more than aop nicks (which happens all the time anyway).
brandon / lorddracula CSop and AA of serenity.* servers Exploits, Routing, Oper Training, and Webteam
If an Sop nick were to be compromised, the channel ops would no longer be able to handle the situation on their own, since that person would be unkickable and unbannable.
Well, I would say, the right solution here is to implement the best available reasonable methods to prevent compromise of the SOP nicknames, or to require further measures to authenticate SOP access, if necessary...
But if a SOP nick were to be compromised, they would most likely use SOP powers to delete the AOPs attempting to kick. Ops cannot really effectively deal with a compromised SOP login, period. They never really could..
In fact, the rogue SOP may use SOP powers to purge the AOP list completely and issue a mass kick, or perform an AKICK equivalent to *!*@*.*...
In the long run, if a nickname with high privileges is compromised by a bad person, there _will_ be a disruption to normal channel activity, until the abuse can get properly dealt with by the founder an/or a SA.
This just isn't realistic, and it wouldn't really solve the problem. People would just seek to compromise sop nicks more than aop nicks (which happens all the time anyway).
-- -J
While yes, a rogue SOp could do damage that AOps couldn't handle, other SOps would be immune to being removed from the list, and would be able to mitigate the damage caused for the most part. If the SOp in question could not be kicked or banned, then the other SOps would be powerless. In addition, the founder would also be unable to kick or ban the miscreant until such a time that he remembered to remove the SOp from the SOp list. This proposal creates far more room for abuse that would be harder to handle than it proposes to solve.
On Thu, Apr 16, 2009 at 8:41 AM, James Hess mysidia@gmail.com wrote:
If an Sop nick were to be compromised, the channel ops would no longer be able to handle the situation on their own, since that person would be unkickable and unbannable.
Well, I would say, the right solution here is to implement the best available reasonable methods to prevent compromise of the SOP nicknames, or to require further measures to authenticate SOP access, if necessary...
But if a SOP nick were to be compromised, they would most likely use SOP powers to delete the AOPs attempting to kick. Ops cannot really effectively deal with a compromised SOP login, period. They never really could..
In fact, the rogue SOP may use SOP powers to purge the AOP list completely and issue a mass kick, or perform an AKICK equivalent to *!*@*.*...
In the long run, if a nickname with high privileges is compromised by a bad person, there _will_ be a disruption to normal channel activity, until the abuse can get properly dealt with by the founder an/or a SA.
This just isn't realistic, and it wouldn't really solve the problem.
People
would just seek to compromise sop nicks more than aop nicks (which
happens
all the time anyway).
-- -J _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
On Thu, Apr 16, 2009 at 9:21 AM, Vin King vin.king@gmail.com wrote:
mitigate the damage caused for the most part. If the SOp in question could not be kicked or banned, then the other SOps would be powerless. In
I would say that a proper implementation should allow other SOPs (or higher) to kick SOPs, regardless of the normal restriction.
I would expect the logic would look something like
int can_user_kick( aClient * actor, aClient * victim, aChannelAccessContext * context ) {
if ( channel_access_level(victim, context) >= ACCESS_SOP && is_channel_access_level_higher_than(actor, victim, context) ) return KICKRESULT_SORRY_THEYARE_A_SOP;
return KICKRESULT_YESYOUCAN; }
-- -J
Dear Concerned head:
Can u design some command by which channel owner can block or restrict mkick in channel? Regards, Malik Kanji Predictor on DALnet
________________________________ From: James Hess mysidia@gmail.com To: Vin King vin.king@gmail.com Cc: dalnet-src@dal.net; lorddracula lorddracula@dal.net Sent: Thursday, April 16, 2009 10:25:11 PM Subject: Re: [DALnet-src] Suggestion
On Thu, Apr 16, 2009 at 9:21 AM, Vin King vin.king@gmail.com wrote:
mitigate the damage caused for the most part. If the SOp in question could not be kicked or banned, then the other SOps would be powerless. In
I would say that a proper implementation should allow other SOPs (or higher) to kick SOPs, regardless of the normal restriction.
I would expect the logic would look something like
int can_user_kick( aClient * actor, aClient * victim, aChannelAccessContext * context ) {
if ( channel_access_level(victim, context) >= ACCESS_SOP && is_channel_access_level_higher_than(actor, victim, context) ) return KICKRESULT_SORRY_THEYARE_A_SOP;
return KICKRESULT_YESYOUCAN; }
-- -J _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
Masskicking is removes of all persons on a channel. Everyone in the channel will be kicked and banned. If you are outranked by any individuals on the channel, this command will NOT be accepted. As explained above there are already restrictions in place to ensure that masskicking will not be accepted on users with a higher access level that those who call the masskick. Apart from that, adding the masskick option as a SET variable would require re-writing in services. It could be considered a good suggestion, but it serves no real purpose. Choose channel operators wisely.
-- On 17 Apr 2009, at 13:14, Raj wrote:
Dear Concerned head: Can u design some command by which channel owner can block or restrict mkick in channel? Regards, Malik Kanji Predictor on DALnet
-
BILaL Bhatty -
James Hess -
lorddracula -
Raj -
Steffan Wood -
Vin King