View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005515 | unreal | ircd | public | 2019-12-29 20:56 | 2020-02-08 10:19 |
| Reporter | PeGaSuS | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | Unix | OS | Ubuntu | OS Version | 18.04 LTS |
| Product Version | 5.0.0 | ||||
| Summary | 0005515: Restrict /INVITE command to users having at least +h (halfop) in the channel | ||||
| Description | Currently, the /INVITE command can be executed by anyone in the channel (being registered or not), which can lead to some abuse from possible botnets or annoying users. Would be good to deny this command to any user that isn't at least +h (halfop) in the channel. Cheers! | ||||
| Steps To Reproduce | 1) Join any user (registered or not) to any channel (registered or not) 2) Type: /INVITE nick 3) The command will be executed and the target will be invited | ||||
| Tags | access control, access lists, security | ||||
| 3rd party modules | |||||
|
|
I've just tested this in 5.0.2, and INVITE behaves just like in 4.x, ie. restricted to chanops (+o) when channel is set +i, and unrestricted otherwise. The only thing that is a little unexpected is that a halfop cannot use INVITE on a +i channel, but they can set mode -i … Apart from that, I would say that the current behaviour is not a regression from previous versions. |
|
|
I didn't said it was a regression. I'm just saying that a user that doesn't have any status in the channel shouldn't be able to use /INVITE. Currently, ANY user can use the /INVITE command in ANY channel, despite having access or not. That should be restricted to +h or higher. |
|
|
i don't know about this. i mean.. unreal can be used without services, so therefore there will be no registered users at all. so restrict the /invite command is a little bit excessive. feature request? maybe. so this would be a setting in the conf, that you want to restrict using the command for channel ops or halfops or whatever (like the setting which allows you to set the right which you get when you join to a chan (level-on-join)), but other than that, i don't think that this kind of core restriction should be made. |
|
|
docu: INVITE <nick> <channel> m_invite Invites someone to join a channel. If you are chanop and the channel is +i then this makes the user walk through the +i (invite only) mode, or similarly if the user is banned (+b) an /INVITE allows the user to walk through the ban and still join. When executed by a non-chanop (so regular user) then no special behavior happens and the user receives just only the "user XYZ invited you to join #chan" message. btw if this is not a bug, which is clear, then the severity should be "feature" :) |
|
|
Seconded. AFAICT, the current behaviour is fully compliant with RFC2812 (see https://tools.ietf.org/html/rfc2812#section-3.2.7) and therefore shouldn't be changed, IMHO. |
|
|
so, you rather want any user (registered or not) to join your channel (registered or not) and start using /INVITE in any users that are in other channels and might don't want to join your channel? don't you think that said users would get annoyed from so much /INVITE spam? |
|
|
PeGaSuS, it works as it should that's what we said. unreal givices the opportunity though to protect the channel or other users via these options: https://www.unrealircd.org/docs/Set_block#set::restrict-commands set::restrict-commands so here, you can just delay the /invite command usage after somebody connects. https://www.unrealircd.org/docs/Set_block#set::anti-flood::invite-flood set::anti-flood::invite-flood Syntax: set::anti-flood::invite-flood <count>:<period> Invite flood protection: this limits /INVITE to a rate of 'count' per 'period' seconds. The default is 4:60 which means 4 /INVITE's per 60 seconds. here you can set an anti-flood protection. so if there are abusers in your network, you can just set these. |
|
|
I think this can be closed. As others pointed out, this is how the INVITE command works. If you have a flood/bot problem then the restrict-commands will be a useful feature (and restricting it to +hoaq is not so much). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-12-29 20:56 | PeGaSuS | New Issue | |
| 2019-12-29 20:56 | PeGaSuS | Tag Attached: access control | |
| 2019-12-29 20:56 | PeGaSuS | Tag Attached: access lists | |
| 2019-12-29 20:56 | PeGaSuS | Tag Attached: security | |
| 2020-01-28 17:47 | Le_Coyote | Note Added: 0021265 | |
| 2020-01-28 18:13 | PeGaSuS | Note Added: 0021266 | |
| 2020-01-28 18:16 | Lord255 | Note Added: 0021267 | |
| 2020-01-28 18:20 | Lord255 | Note Added: 0021268 | |
| 2020-01-28 19:36 | Le_Coyote | Note Added: 0021269 | |
| 2020-01-28 22:45 | PeGaSuS | Note Added: 0021270 | |
| 2020-01-29 00:09 | Lord255 | Note Added: 0021273 | |
| 2020-02-08 10:19 | syzop | Assigned To | => syzop |
| 2020-02-08 10:19 | syzop | Status | new => closed |
| 2020-02-08 10:19 | syzop | Resolution | open => no change required |
| 2020-02-08 10:19 | syzop | Note Added: 0021290 |
