View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002217 | unreal | ircd | public | 2004-12-04 03:15 | 2007-04-19 04:57 |
| Reporter | Stealth | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | wont fix | ||
| Summary | 0002217: Setting channel mode +z / who +m flags | ||||
| Description | I think it would be a good idea to force non-ssl users to part a channel when someone sets mode +z. This will make it easier to do on large networks, since the channel op/admin/founder will not need to whois everyone and remove non-ssl users. I know ConferenceRoom is a nad word here, but when channel mode +z is set, it will automatically kick all non-ssl users with the setters nick. Example is in additional info. | ||||
| Additional Information | * Kael[games] was kicked by Stealthie (Channel permits encrypted traffic only) * Stealthness was kicked by Stealthie (Channel permits encrypted traffic only) * Stealth was kicked by Stealthie (Channel permits encrypted traffic only) * Alex_D00m was kicked by Stealthie (Channel permits encrypted traffic only) * Luanna was kicked by Stealthie (Channel permits encrypted traffic only) * Stealthie sets mode: +z | ||||
| 3rd party modules | |||||
|
|
It sounds a bit scary to me... a nice way to masskick everyone? I know.. services should take care of channels, but still.. it can create a lot of traffic and havoc if a simple op does this (especially in a big channel). Not to mention, that in most cases I don't think this action is prefered anyway... I wouldn't like it at least. |
|
|
I agree, this could cause quite a bit of trouble, and I don't really think it is worth it. Think about the problems: 1.) What if all the ops (including yourself) are non-SSL? Setting +z will leave the channel op less! That's very bad, especially if you don't have services. 2.) What about accidental mode changes? I know many times people accidentily type /mode #chan nick +o instead of /mode #chan +o nick, I know I've done it, so what happens if they accidentily type /mode #chan zombie +o and instead of giving him +o, it kicks the entire channel. 3.) As Syzop mentioned, what about a bad-op? He decides to take over the channel, and rather than having to kick people manually (and after the first 4-5 kicks, someone would likely deop him), he just types /mode #chan +z and now everyone is gone instantly. Would it be more convenient? Yes. However, I don't know of any channels that just "decide" to be +z. Usually they always are, or they never are. Meaning, something named #SecureChat is probably always going to be +z, however something named #Chat is probably never going to be. So my guess is, this would rarely be wanted, and would mostly cause trouble. |
|
|
hmmm .... why not a simply way ?! :) Allow Non-Opers to /who +cm #chan z .. the masskick things can be done by scripts or whatever :p *edit* off topic : I tink is better to allow all /who +cm modes for Non-Opers and have a new option like: set::restrict-whoflags *edit* |
|
|
Yeah I thought of allowing ssl in the who +m thing too, was discussed in another bugid I think. [quote]off topic : I tink is better to allow all /who +cm modes for Non-Opers and have a new option like: set::restrict-whoflags[/quote] Nahhh |
|
|
[quote]*edit* off topic : I tink is better to allow all /who +cm modes for Non-Opers and have a new option like: set::restrict-whoflags *edit*[/quote] The problem is, there are certain modes you NEVER want people to be able to search by. For example, +i and +H. So if an admin forgot to add a restrict-whoflags, it could be dangerous. |
|
|
this is crazy but just a suggestion, if the room is set on +z any non ssl clients cant privmsg channel, notice channel, (unless +o +a or +q to allow them to tell users that they cannot talk becuz they are not ssl) this also allows other ops to correct any *mistakes* that should happen, or prevent a channel take over. in the event of +iz, any knock Requests are rejected to the non ssl clients, also add a command into the usercmds for founders only to use, which would kick all non ssl users, i know this would be usless without services, but, you have modes which can only be set by founders, why not a command?!? |
|
|
codemastr you are right I forgot about the +i/H/S/p (ich war glaub ich zu müde :p) but why not z/h/V/r mabye R/T/w ?! can be very useful ... |
|
|
[quote]but why not z/h/V/r mabye R/T/w ?! can be very useful ..[/quote] z? as discussed, sounds good.. h? I suppose (unless hidden oper) V? why? I don't see any reason to r? Maybe? Looks useful R? No, why disclosing such information? T? No, why disclosing such information? w? Huh?? :)) I think only certain ones should be explicitly enabled, not the other way around... It is not "proper behavior" IMO to just disclose all kinds of info about users like what kind of (flood) protection modes they have enabled. Public info is fine with me however (z/h/r). [Yes, I know.. if you send a msg or whatever you'll know whether for example +R was set, but I don't think it's good to disclose such information "en masse".. like giving an attacker 'hey, here's a big list of all users that do not have the .. protection mode set '] |
|
|
z and h I'd definately agree with, +r maybe, the other ones I'd say no. The reason is, remember, you can negate to. So you want to do /who +m R to find users who are +R. One of the main purposes of +R is to stop spam. So as a spam bot, I do /who -m R this gives me a list of everyone who is NOT +R. So now I can find exactly the people my spam can get to. |
|
|
For what is +r useful? To get a complete list of the network? That would be the case in networks with services. Even if you are going to restrict it to the users of the channels, you are currently in, there is no real reason to make this information public, in my opinion. |
|
|
@rocko >> "there is no real reason to make this information public, in my opinion." this is already "public" in a channel by using /WHOIS (a few lines of code for your client and you can get a list of all +r user using "RAW 307") the same for +z(done by "RAW 320" and "is a Secure Connection") and +h(done by "RAW 310") (well is an oper hiden then no :P) forget R/T/w :p as I said mabye :) |
|
|
You people are all forgetting one main point about the difference between WHO and WHOIS. WHOIS: Lets you get information about a user if you know the persons nick. You cannot WHOIS a wildcard mask and "filter" the results to get information. WHO: Who lets you use a wildcard mask and will return all results from a whole network. In my opinion, the WHO flags are just fine. There is no reason any normal user would want to get a list of all the registered people, or the +z people. I think if a who flag for +z is made, it should require a channel parameter from normal users. Opers can simply use "+m z" to see all secure connections on a network. Perhaps for the secure flag, it should be used like "WHO +z <#channel> [mask]" for non-opers. I dont feel comfortable giving non-opers the power to use WHO in the other ways, I can think of so many ways it can be abused. |
|
|
[quote] You people are all forgetting one main point about the difference between WHO and WHOIS.[/quote] Nearly everyone in this thread is very much aware of that exact point, don't worry. In fact, all above messages are about it :P [quote]For what is +r useful? To get a complete list of the network?[/quote] The whoflags stuff only _filters_ results, so it doesn't give you any _more_ results than /who without parameters would. [quote]Even if you are going to restrict it to the users of the channels, you are currently in, there is no real reason to make this information public, in my opinion.[/quote] It can be useful... like if I'm an op in #blah which is a 40 user channel, I can quickly see who is kinda-more-trusted.. like, assuming services had email confirmation, I can at least be somewhat sure that the +m r people are not drones. Or just.. I can see immediately that X,Y,Z are really X, Y, Z. I mean, I know I would use it from time to time if it existed, then again.. I'm usually an oper anyway ;p. Stuff like +z, as mentioned, has it's uses too. Now I don't understand how this "require a channel" stuff would 'help'.. I mean if I'm in like 10 channels and someone is evil (and I don't see how in case of r/z) then it just requires me 10 WHO operations instead of 1.. well.. great :P. And for all those users that are not in my 'common channels' but still appear in who... they are umode -i, well.. if they want to be visible, then I don't see a problem with showing them in the results :p. Anyway, if we would widen these flagstuff, perhaps we can add set::restrict-who-umode-flags or something. Still, I don't want to "kill" the discussion by just offering this option ("oh well, then I don't care what you decide and I'll just use that then"-style), I too want a 'secure default', but I just don't see much problems with +h/+z/+r, perhaps someone can come up with a few? :P. |
|
|
+h/+z/+r, perhaps someone can come up with a few <flooderX> lets see which ircops/helpers we can flood with my new X amount of bots. <flooderX> well the who list now shows me all the helpops and they arnt ircops so great :D lets have some fun, sure the helpop has a ignore and a anti flood funcation prolly but still, far fetched but... <hackerX> SSL sucks, cant add sniffers and stuff nomore, but with the new +z who thing, i can find targets which i know are grantted to work and sniff, even ircops who arnt +H! or... <flooderY> hey join #something and get +z removed so i can flood the room, ur a op there n i really hate the room owner, hes in this other room giving me sh!t n hes on ssl meaning i cant flood or join his room. <someone> sure m8 hangon.... erm,yeah,still, makes it easier for a flooder in some ways. there are somescarnios ican think of with +r and spambots/ flooders but im not gonna go into them coz they r really far fetched but could be very easily possibly coded, |
|
|
[quote]<flooderX> well the who list now shows me all the helpops and they arnt ircops so great :D lets have some fun, [/quote] All helpops are IRCops. Every single oper block implicitely has the locop flag. Therefore this is not valid. [quote]<hackerX> SSL sucks, cant add sniffers and stuff nomore, but with the new +z who thing, i can find targets which i know are grantted to work and sniff, even ircops who arnt +H![/quote] You have *always* been able to do a /who 0 o to get a list of opers, even from the first version of Unreal. I've yet to hear one report of it being used to attack people. In any case, as Syzop said, this doesn't give you more info than you already can get. Meaning, yes /who and /whois are different. But you can combine them. For example, I could do a /who *, then use a script to do a /whois on each one, and determine if they are +z. The tools are available, this would simply make it easier to determine who is +z. So a "bad guy" can already do it. So why hurt the "good guys" if it doesn't even prevent any problems? |
|
|
>All helpops are IRCops. Every single oper block implicitely has the locop flag. Therefore this is not valid. Let's not forget that Anope gives umode +h to anyone who's op in the help channel :P (IRCop or not). But as was said, we're talking about information that's publicly viewable anyway (/whois). All this does is allow people to *filter* /who searches based on this information. To be honest, searching for +r doesn't really help spambots (unless you have some obscure module that denies +R unless you identify or something but why would you? :P). |
|
|
>All helpops are IRCops. Every single oper block implicitely has the locop flag. Therefore this is not valid. Isnt there a muodule which allows users to log into the server as helpops only?these users would be affected into this as they would have +h without ircop. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-12-04 03:15 | Stealth | New Issue | |
| 2004-12-04 11:52 | syzop | Note Added: 0008481 | |
| 2004-12-04 12:28 |
|
Note Added: 0008483 | |
| 2004-12-04 13:01 | crazy | Note Added: 0008487 | |
| 2004-12-04 13:12 | crazy | Note Edited: 0008487 | |
| 2004-12-04 14:45 | syzop | Note Added: 0008488 | |
| 2004-12-04 14:55 |
|
Note Added: 0008489 | |
| 2004-12-04 17:10 | White_Magic | Note Added: 0008490 | |
| 2004-12-05 12:38 | crazy | Note Added: 0008506 | |
| 2004-12-05 13:02 | syzop | Summary | Setting channel mode +z => Setting channel mode +z / who +m flags |
| 2004-12-05 13:11 | syzop | Note Added: 0008509 | |
| 2004-12-05 13:25 |
|
Note Added: 0008511 | |
| 2004-12-06 04:22 | Rocko | Note Added: 0008520 | |
| 2004-12-06 07:27 | crazy | Note Added: 0008521 | |
| 2004-12-06 11:50 | Stealth | Note Added: 0008525 | |
| 2004-12-06 11:50 | Stealth | Note Edited: 0008525 | |
| 2004-12-06 12:34 | syzop | Note Added: 0008527 | |
| 2004-12-09 20:08 | White_Magic | Note Added: 0008567 | |
| 2004-12-09 22:41 |
|
Note Added: 0008572 | |
| 2004-12-10 12:32 | aquanight | Note Added: 0008582 | |
| 2004-12-10 12:55 | White_Magic | Note Added: 0008583 | |
| 2007-04-19 04:57 |
|
Status | new => closed |
| 2007-04-19 04:57 |
|
Resolution | open => wont fix |
